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Changes  in  This  Edition 

This  document  is  an  updated  version  of  and  replaces  Range  Commanders  Council  (RCC) 
Document  106-15  (Part  1:  Telemetry  Standards  [July  2015]).  The  RCC  Telemetry  Group  (TG) 
made  an  extensive  effort  to  produce  a  well-coordinated  and  useful  document.  The  following  is  a 
summary  of  these  efforts. 

a.  Task  TG-128:  2017  Updates  to  Digital  Telemetry  Recorder  Standards 

OBJECTIVE/SCOPE:  Update  IRIG  106  Chapter  6,  9,  10  to  include  data  recorder 
capabilities  required  by  the  RCC  members.  Update  Test  Method  (118)  and  Handbook 
(123). 

b.  Task  TG-131:  Define  Interference  Protection  Criteria  (IPC)  for  RE  Telemetry  Systems 

OBJECTIVE/SCOPE:  Telemetry  operations  continue  to  be  threatened  by  new  sources  of 
RE  interference  from  services  sharing  the  telemetry  bands  or  operating  in  adjacent  bands. 
The  Telemetry  Standards  do  not  contain  any  guidance  for  determining  appropriate  levels 
of  protection  to  ensure  our  systems  will  not  be  impacted  by  these  sources  of  interference. 
This  task  seeks  to  define  the  process  and  criteria  to  be  used  for  evaluating  potential 
interference  to  Range  telemetry  receiving  systems. 

c.  Task  TG-133:  Updates  to  TMATS  for  106-17 

OBJECTIVE/SCOPE:  To  enhance  the  content  of  the  Telemetry  Attributes  Transfer 
Standard  (TMATS)  as  needed  to  keep  it  current  with  the  data  standards  in  the  remainder 
of  106. 

d.  Task  TG-139:  Define  PCM  Clocking  standards  for  106-17 

OBJECTIVE/SCOPE:  Define  clocking  standards  for  ground  equipment  that  process 
chapter  4  NRZ-E  PCM. 

e.  Task  TG-140:  Update  106-17  Appendix  N  Transmitter  and  Receiver  Commands 

OBJECTIVE/SCOPE:  Update  RCC  Document  IRIG  106,  Appendix  N  to  define 
additional  transmitter  commands  required  to  be  common  at  the  MRTEBs  to  support  real¬ 
time  command  and  control  of  serial  streaming  telemetry  (SST)  transmitter  characteristics. 
This  task  will  also  define  TM  receiver  commands  for  interoperability. 

f.  Task  TG-141:  Update  IRIG  106  with  Standards  for  Data  Quality  Metrics  (DQM)  and 
Data  Quality  Encapsulation  (DQE)  for  use  in  Telemetry  Receivers 

OBJECTIVE/SCOPE:  Define  a  Data  Quality  Metric  (DQM)  that  correlates  with 
telemetry  link  Bit  Error  Performance  (BEP)  and  also  define  a  Data  Quality  Encapsulation 
(DQE)  standard  that  defines  how  to  transport  DQM  with  the  received  telemetry  data. 

g.  Task  TG-143:  IRIG  106  Ch.  21-28  Publication 
OBJECTIVE/SCOPE: 

(1)  Incorporate  group  and  industry  comments. 

(2)  Publish  Chapters  21  through  28  of  IRIG  106 

h.  Task  TG-I44:  Update  IRIG  106  Chapter  7. 
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OBJECTIVE/SCOPE:  Update  Chapter  7  and  TMATS  in  chapter  9  to  support  defining  a 
subset  of  the  PCM  minor  frame  for  chapter  7  data.  Make  chapter  7  and  appendix  Q 
clearer  on  how  to  implement  chapter  7  compliant  systems. 
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Preface 

The  TG  of  the  RCC  has  prepared  this  doeument  to  foster  the  eompatibility  of  telemetry 
transmitting,  reeeiving,  and  signal  proeessing  equipment  at  the  member  ranges  under  the 
cognizance  of  the  RCC.  The  range  commanders  highly  recommend  that  telemetry  equipment 
operated  by  the  ranges  and  telemetry  equipment  used  in  programs  that  require  range  support 
conform  to  these  standards. 

These  standards  do  not  necessarily  define  the  existing  capability  of  any  test  range,  but 
constitute  a  guide  for  the  orderly  implementation  of  telemetry  systems  for  both  ranges  and  range 
users.  The  scope  of  capabilities  attainable  with  the  utilization  of  these  standards  requires  the 
careful  consideration  of  tradeoffs.  Guidance  concerning  these  tradeoffs  is  provided  in  the  text. 
The  standards  provide  the  necessary  criteria  on  which  to  base  equipment  design  and 
modification.  The  ultimate  purpose  is  to  ensure  efficient  spectrum  utilization,  interference-free 
operation,  interoperability  between  ranges,  and  compatibility  of  range  user  equipment  with  the 
ranges. 

This  standard  is  complemented  by  a  companion  series:  RCC  Document  118,  Test 
Methods  for  Telemetry  Systems  and  Subsystems;  RCC  Document  119,  Telemetry  Applications 
Handbook;  RCC  Document  123,  IRIG  106  Chapter  10  Programmers  Handbook;  and  RCC 
Document  124,  Telemetry  Attributes  Transfer  Standard  (TMATS)  Handbook. 

The  policy  of  the  TG  is  to  update  the  telemetry  standards  and  test  methods  documents  as 
required  to  be  consistent  with  advances  in  technology. 

Please  direct  any  questions  to: 


Secretariat,  Range  Commanders  Council 
ATTN:  CSTE-WS-RCC 
1510  Headquarters  Avenue 

White  Sands  Missile  Range,  New  Mexico  88002-5110 
Telephone:  (575)  678-1107,  DSN  258-1107 

E-mail:  usarmv.wsmr.atec.list.rcc@mail.mil 
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CHAPTER  1 
Introduction 

The  Telemetry  Standards  address  the  here-to-date  conventional  methods,  techniques,  and 
practices  affiliated  with  aeronautical  telemetry  applicable  to  the  member  RCC  ranges.  The  first 
1 1  chapters  are  generally  devoted  to  a  different  element  of  the  telemetry  system  or  process. 
Chapters  21  through  28  address  the  topic  of  network  telemetry.  These  chapters  are  to  be  used 
together  to  define  the  various  aspects  of  network  telemetry. 

Reference  documents  are  identified  at  the  point  of  reference.  Commonly  used  terms  are 
defined  in  standard  reference  glossaries  and  dictionaries.  Definitions  of  terms  with  special 
applications  are  included  when  the  term  first  appears,  generally  in  appendices  of  individual 
chapters.  Radio  frequency  terms  are  defined  in  the  Manual  of  Regulations  and  Procedures  for 
Federal  Radio  Frequency  Management.  Copies  of  that  manual  may  be  obtained  from: 

Executive  Secretary,  Interdepartmental  Radio  Advisory  Committee  (IRAC) 

U.S.  Department  of  Commerce,  National  Telecommunications  and  Information 
Administration  (NTIA) 

Room  1605,  HCHB  Building 

14th  and  Constitution  Avenue,  N.W. 

Washington,  D.C.  20230 
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CHAPTER  2 

Transmitter  and  Receiver  Systems 

2.1  Radio  Frequency  Standards  for  Telemetry 

These  standards  provide  the  criteria  to  determine  equipment  and  frequency  use 
requirements  and  are  intended  to  ensure  efficient  and  interference-free  use  of  the  radio  frequency 
(RF)  spectrum.  These  standards  also  provide  a  common  framework  for  sharing  data  and 
providing  support  for  test  operations  between  ranges.  The  RF  spectrum  is  a  limited  natural 
resource;  therefore,  efficient  use  of  available  spectrum  is  mandatory.  In  addition,  susceptibility 
to  interference  must  be  minimized.  Systems  not  conforming  to  these  standards  require 
justification  upon  application  for  frequency  allocation,  and  the  use  of  such  systems  is  highly 
discouraged.  The  standards  contained  herein  are  derived  from  the  National  Telecommunications 
and  Information  Administration’s  (NTIA)  Manual  of  Regulations  and  Procedures  for  Federal 
Radio  Frequency  Management.  * 


2.2  Bands 

The  bands  used  for  telemetry  are  described  in  Table  2-1. 


Table  2-1.  Telemetry  Frequency  Allocations 

Frequency 
Range  (MHz) 

Unofficial 

Designation 

Comments 

Refer 

to: 

1435-1525 

Lower  L-band 

Telemetry  primary  service  (part  of  mobile  service)  in 
USA 

2.2.1 

1525-1535 

Lower  L-band 

Mobile  satellite  service  (MSS)  primary  service, 
telemetry  secondary  service  in  USA 

2.2.1 

2200-2290 

Lower  S-band 

Telemetry  co-primary  service  in  USA 

2.2.2 

2310-2360 

Upper  S-band 

Wireless  Communications  Service  (WCS)  and 
Broadcasting-Satellite  Service  (BSS)  primary  services, 
telemetry  secondary  service  in  USA 

2.2.3 

2360-2395 

Upper  S-band 

Telemetry  primary  service  in  USA 

2.2.3 

4400-4940 

Lower  C-band 

See  Paragraph  2.2.4 

2.2.4 

5091-5150 

Middle  C-band 

See  Paragraph  2.2.5 

2.2.5 

5925-6700 

Upper  C-band 

See  Paragraph  2.2.6 

2.2.6 

The  1755-1850  MHz  band  (unofficially  called  “upper  L-band”)  can  also  be  used  for 
telemetry  at  many  test  ranges,  although  it  is  not  explicitly  listed  as  a  telemetry  band  in  the  NTIA 
Table  of  Frequency  Allocations.^  The  mobile  service  is  a  primary  service  in  the  1755-1850  MHz 
band  and  telemetry  is  a  part  of  the  mobile  service.  Since  the  1755-1850  MHz  band  is  not 
considered  a  standard  telemetry  band  per  this  document,  potential  users  must  coordinate,  in 


'  National  Telecommunications  and  Information  Administration.  “Manual  of  Regulations  and  Procedures  for 
Federal  Radio  Frequency  Management.”  September  2015.  May  be  superseded  by  update.  Retrieved  23  March 
2017.  Available  at  https://www.ntia.doc.gov/files/ntia/publications/manual  sep  2015.pdf 
^  Code  of  Federal  Regulations,  Table  of  Frequency  Allocations,  title  47,  sec.  2.106. 
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advance,  with  the  individual  range(s)  and  ensure  use  of  this  band  can  be  supported  at  the  subject 
range  and  that  it  will  meet  their  technical  requirements.  While  these  band  designations  are 
common  in  telemetry  parlance,  they  may  have  no  specific  meaning  to  anyone  else.  Telemetry 
assignments  are  made  for  testing^  manned  and  unmanned  aircraft,  for  missiles,  space,  land,  and 
sea  test  vehicles,  and  for  rocket  sleds  and  systems  carried  on  such  sleds.  Telemetry  assignments 
are  also  made  for  testing  major  components  of  the  aforementioned  systems. 

2.2.1  Allocation  of  the  Lower  L-Band  (1435  to  1535  MHz) 

This  band  is  allocated  in  the  United  States  and  Possessions  (US&P)  for  government  and 
nongovernmental  aeronautical  telemetry  use  on  a  shared  basis.  The  Aerospace  and  Flight  Test 
Radio  Coordinating  Council  (AFTRCC)  coordinates  the  non-governmental  use  of  this  band.  The 
frequencies  in  this  range  will  be  assigned  for  aeronautical  telemetry  and  associated  remote- 
control  operations"*^  for  testing  of  manned  or  unmanned  aircraft,  missiles,  rocket  sleds,  and  other 
vehicles  or  their  major  components.  Authorized  usage  includes  telemetry  associated  with 
launching  and  reentry  into  the  earth's  atmosphere  as  well  as  any  incidental  orbiting  prior  to 
reentry  of  manned  or  unmanned  vehicles  undergoing  flight  tests.  The  following  frequencies  are 
shared  with  flight  telemetering  mobile  stations:  1444.5,  1453.5,  1501.5,  1515.5,  1524.5,  and 
1525.5  MHz. 

2.2.1. 1  1435  to  1525  MHz 

This  frequency  range  is  allocated  for  the  exclusive  use  of  aeronautical  telemetry  in  the 
United  States  of  America. 

2.2.1.2  1525  to  1530  MHz 

The  1525  to  1530  MHz  band  was  reallocated  at  the  1992  World  Administrative  Radio 
Conference.  The  mobile-satellite  service  is  now  a  primary  service  in  this  band.  The  mobile 
service,  which  includes  aeronautical  telemetry,  is  now  a  secondary  service  in  this  band. 

2.2.1.3  1530  to  1535  MHz 

The  maritime  mobile-satellite  service  is  a  primary  service  in  the  frequency  band  from 
1530  to  1535  MHz.^  The  mobile  service  (including  aeronautical  telemetry)  is  a  secondary 
service  in  this  band. 

2.2.2  Allocation  of  the  Lower  S-Band  (2200  to  2300  MHz) 

No  provision  is  made  in  this  band  for  the  flight  testing  of  manned  aircraft. 

2.2.2. 1  2200  to  2290  MHz 

These  frequencies  are  shared  equally  by  the  United  States  Government's  fixed,  mobile, 
space  research,  space  operation,  and  the  Earth  Exploration-Satellite  Services  (EESS),  and  include 
telemetry  associated  with  launch  vehicles,  missiles,  upper  atmosphere  research  rockets,  and 
space  vehicles  regardless  of  their  trajectories. 


^  A  telemetry  system  as  defined  here  is  not  critical  to  the  operational  (tactical)  function  of  the  system. 

The  word  used  for  remote-control  operations  in  this  band  is  telecommand. 

^  Reallocated  as  of  1  January  1990. 
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2.22.2  2290  to  2300  MHz 

Allocations  in  this  range  are  for  the  spaee  researeh  serviee  (deep  spaee  only)  on  a  shared 
basis  with  the  fixed  and  mobile  (exeept  aeronautieal  mobile)  serviees. 

2.2.3  Alloeation  of  the  Upper  S-Band  (2310  to  2395  MHz) 

This  band  is  allocated  to  the  fixed,  mobile,  radiolocation,  and  BSS  in  the  United  States  of 
Ameriea.  Government  and  nongovernmental  telemetry  users  share  this  band  in  a  manner  similar 
to  that  of  the  L-band.  Telemetry  assignments  are  made  for  flight-testing  of  manned  or  unmanned 
aircraft,  missiles,  space  vehicles,  or  their  major  components. 

2.2.3. 1  2310  to  2360  MHz 

These  frequeneies  have  been  realloeated  and  were  auetioned  by  the  Federal 
Communieations  Commission  (FCC)  in  April  1997.  The  WCS  is  the  primary  serviee  in  the 
frequencies  2305-2320  MHz  and  2345-2360  MHz.  The  BSS  is  the  primary  serviee  in  the  2320- 
2345  MHz  band.  In  the  2320-2345  MHz  band,  the  mobile  and  radioloeation  services  are 
alloeated  on  a  primary  basis  until  a  broadeasting-satellite  (sound)  serviee  has  been  brought  into 
use  in  sueh  a  manner  as  to  affeet  or  be  affeeted  by  the  mobile  and  radioloeation  serviees  in  those 
service  areas 

2.2.32  2360  to  2395  MHz 

The  mobile  serviee  (ineluding  aeronautieal  telemetry)  is  a  primary  serviee  in  this  band. 

2.2.4  Alloeation  of  the  Lower  C-Band  (4400  to  4940  MHz) 

Telemetry  is  an  operation  that  is  currently  allowed  under  the  mobile  service  allocation. 

2.2.5  Allocation  of  the  Middle  C-Band  (5091  to  5150  MHz) 

The  proeess  of  ineorporating  aeronautieal  telemetry  operations  into  the  NTIA  Table  of 
Frequeney  Allocations  for  this  band  has  been  initiated  but  not  yet  completed. 

2.2.6  Alloeation  of  the  Upper  C-Band  (5925  to  6700  MHz) 

This  band  is  not  eurrently  alloeated  as  a  government  band.  The  process  of  incorporating 
federal  government  use  of  aeronautical  telemetry  operations  into  the  NTIA  Table  of  Frequeney 
Alloeations  for  this  band  has  been  initiated  but  not  yet  eompleted. 

2.3  Telemetry  Transmitter  Systems 

Telemetry  requirements  for  air,  spaee,  and  ground  systems  are  aeeommodated  in  the 
appropriate  bands  as  described  in  Section  2.2. 

2.3.1  Center  Frequency  Tolerance 

Unless  otherwise  dietated  by  a  partieular  applieation,  the  frequeney  toleranee  for  a 
telemetry  transmitter  shall  be  ±0.002%  of  the  transmitter's  assigned  eenter  frequeney. 

Transmitter  designs  shall  eontrol  transient  frequency  errors  associated  with  startup  and  power 
interruptions.  During  the  first  seeond  after  tum-on,  the  transmitter  output  frequency  shall  be 
within  the  oeeupied  bandwidth  of  the  modulated  signal  at  any  time  when  the  transmitter  output 
power  exceeds  -25  decibels  (dB)  referenced  to  one  milliwatt  (dBm).  Between  1  and  5  seeonds 
after  initial  tum-on,  the  transmitter  frequency  shall  remain  within  twiee  the  specified  limits  for 
the  assigned  radio  frequency.  After  5  seeonds,  the  standard  frequeney  toleranee  is  applicable  for 
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any  and  all  operations  where  the  transmitter  power  output  is  -25  dBm  or  greater  (or  produces  a 
field  strength  greater  than  320  microvolts  [pV]/meter  at  a  distance  of  30  meters  from  the 
transmitting  antenna  in  any  direction).  Specific  uses  may  dictate  tolerances  more  stringent  than 
those  stated. 

2.3.2  Output  Power 

Emitted  power  levels  shall  always  be  limited  to  the  minimum  required  for  the  application. 
The  output  power  shall  not  exceed  25  watts^.  The  effective  isotropic  radiated  power  (EIRE) 
shall  not  exceed  25  watts. 

2.3.3  Modulation 

The  traditional  modulation  methods  for  aeronautical  telemetry  are  frequency  modulation 
(EM)  and  phase  modulation  (PM).  Pulse  code  modulation  (PCM)/PM  has  been  the  most  popular 
telemetry  modulation  since  around  1970.  The  PCM/EM  method  could  also  be  called  filtered 
continuous  phase  frequency  shift  keying  (CPESK).  The  RE  signal  is  typically  generated  by 
filtering  the  baseband  non-return-to-zero-level  (NRZ-E)  signal  and  then  frequency  modulating  a 
voltage-controlled  oscillator  (VCO).  The  optimum  peak  deviation  is  0.35  times  the  bit  rate  and  a 
good  choice  for  a  premodulation  filter  is  a  multi-pole  linear  phase  filter  with  bandwidth  equal  to 
0.7  times  the  bit  rate.  Both  EM  and  PM  have  a  variety  of  desirable  features  but  may  not  provide 
the  required  bandwidth  efficiency,  especially  for  higher  bit  rates.  When  better  bandwidth 
efficiency  is  required,  the  standard  methods  for  digital  signal  transmission  are  the  Eeher’s 
patented  quadrature  phase  shift  keying  (EQPSK-B  and  EQPSK-JR),  the  shaped  offset  quadrature 
phase  shift  keying  (SOQPSK-TG),  and  the  Advanced  Range  Telemetry  (ARTM)  continuous 
phase  modulation  (CPM).  Each  of  these  methods  offer  constant,  or  nearly  constant,  envelope 
characteristics  and  are  compatible  with  non-linear  amplifiers  with  minimal  spectral  regrowth  and 
minimal  degradation  of  detection  efficiency.  The  first  three  methods  (EQPSK-B,  EQPSK-JR, 
and  SOQPSK-TG)  are  interoperable  and  require  the  use  of  the  differential  encoder  described  in 
Subsection  2. 3. 3. 1.1  below.  Additional  information  on  this  differential  encoder  is  contained  in  0. 
All  of  these  bandwidth-efficient  modulation  methods  require  the  data  to  be  randomized. 
Additional  characteristics  of  these  modulation  methods  are  discussed  in  the  following  paragraphs 
and  in  Section  A.7. 

2.3.3. 1  Characteristics  of  EQPSK-B 

The  EQPSK-B  method  is  described  in  the  Digcom  Inc.  publication,  “FQPSK-B,  Revision 
Al,  Digcom-Feher  Patented  Technology  Transfer  Document,  January  15,  1999 F  This  document 
can  be  obtained  under  a  license  from: 

Digcom  Inc. 

44685  Country  Club  Drive 

El  Macero,  CA  95618 

Telephone:  530-753-0738 

EAX:  530-753-1788 


®  An  exemption  from  this  EIRP  limit  will  be  considered;  however,  systems  with  EIRE  levels  greater  than  25  watts 
will  be  considered  nonstandard  systems  and  will  require  additional  coordination  with  affected  test  ranges. 
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2. 3. 3. 1.1  Differential  Encoding 

Differential  eneoding  shall  be  provided  for  FQPSK-B,  FQPSK-JR,  and  SOQPSK-TG  and 
shall  be  eonsistent  with  the  following  definitions. 

The  NRZ-L  data  bit  sequenee  {bn}  is  sampled  periodieally  by  the  transmitter  at  time 
instants: 

t  =  nTi^  n  =  0,1,2,.... 


where  Tb  is  the  NRZ-L  bit  period. 

Using  the  bit  index  values  n  as  referenees  to  the  beginning  of  symbol  periods,  the 
differential  eneoder  alternately  assembles  I-ehannel  and  Q-channel  symbols  to  form  the 
following  sequenees: 

^2  ’  ^4  ’  ^6  ’••• 

and 

according  to  the  following  rules: 


^ 2ti  ~  ^2n  ®  Q{2n-\) 

n  >  0 

(2-1) 

Q(2n+\)  ~  ^(2w+l)  ®  ^ 2n 

n  >  0 

(2-2) 

Where  ®  denotes  the  exclusive-or  operator,  and  the  bar  above  a  variable  indicates  the  ‘not’  or 
inversion  operator.  Q-channel  symbols  are  offset  (delayed)  relative  to  I-channel 
symbols  by  one  bit  period. 

2. 3. 3. 1.2  Characteristics  of  FQPSK-JR 

The  FQPSK-JR  method  is  a  cross-correlated,  constant  envelope,  spectrum-shaped  variant 
of  FQPSK.  It  assumes  a  quadrature  modulator  architecture  and  synchronous  digital  synthesis  of 
the  I  and  Q-channel  modulating  signals  as  outlined  in  Figure  2-1. 
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Figure  2-1.  FQPSK-JR  Baseband  Signal  Generator 


2 


where  Ts  =  2/rb  is  the  symbol  period. 

The  digital  “JR”  spectrum- shaping  filter  used  for  each  channel  is  a  linear  phase,  finite 
impulse  response  filter.  The  filter  is  defined  in  terms  of  its  impulse  response  sequence  h(n)  in 

^  Feher,  Kamilo,  and  Shuzo  Kato.  Correlated  signal  processor.  US  Patent  4,567,602.  Filed  13  June  1983  and  issued 
28  January  1986. 
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Table  2-2  and  assumes  a  fixed  wavelet  sample  rate  of  p  =  6  samples  per  symbol.  The  JRequiv 
eolumn  is  the  aggregate  response  of  the  easeaded  JRa  and  JRb  filters  aetually  used. 


Table  2-2.  FQPSK-JR  Shaping  Filter  Definition 

Filter  Weight 

JRequiv 

JRa 

JRb 

h(0) 

-0.046875 

2“2 

-(2“3  -f  2“Q 

h(l) 

0.109375 

h(0) 

(2“'  -f  2“Q 

h(2) 

0.265625 

h(0) 

h(l) 

h(3) 

h(2) 

- 

h(0) 

h(4) 

h(l) 

- 

- 

h(5) 

h(0) 

- 

- 

Digital  interpolation  is  used  to  inerease  sample  rate,  moving  all  alias  images  ereated  by 
digital-to-analog  eonversion  suffieiently  far  away  from  the  fundamental  signal  frequeney  range 
so  that  out-of-ehannel  noise  floors  ean  be  well-eontrolled.  The  FQPSK-JR  referenee 
implementations  eurrently  utilize  4-stage  Caseade-Integrator-Comb  interpolators  with  unity 
memory  lag  faetor.^  Interpolation  ratio  “i“  is  adjusted  as  a  funetion  of  bit  rate  sueh  that  fixed 
eutoff  frequeney  post-digital-to-analog  anti-alias  filters  ean  be  used  to  eover  the  entire  range  of 
required  data  rates. ^ 

2. 3. 3. 1.3  Carrier  Suppression 

The  remnant  carrier  level  shall  be  no  greater  than  -30  dB  relative  to  the  carrier  (dBc). 
Additional  information  of  carrier  suppression  can  be  seen  at  Section  A. 7. 

2. 3. 3. 1.4  Quadrature  Modulator  Phase  Map 

Table  2-3  lists  the  mapping  from  the  input  to  the  modulator  (after  differential  encoding 
and  FQPSK-B  or  FQPSK-JR  wavelet  assembly)  to  the  carrier  phase  of  the  modulator  output. 
The  amplitudes  in  Table  2-3  are  ±  a,  where  “a”  is  a  normalized  amplitude. 


Table  2-3.  FQPSK-B  and  FQPSK-JR  Phase  Map 

I  Channel 

Q  Channel 

Resultant  Carrier  Phase 

a 

a 

45  degrees 

-a 

a 

135  degrees 

-a 

-a 

225  degrees 

a 

-a 

315  degrees 

*  Eugene  Hogenauer.  “An  Economical  Class  of  Digital  Eilters  for  Decimation  and  Interpolation”  in  IEEE 
Transactions  on  Acoustics,  Speech,  and  Signal  Processing,  29,  No.  2  (1981):  155-162. 

®  The  EQPSK-JR  definition  does  not  include  a  specific  interpolation  method  and  a  post-D/A  filter  design;  however, 
it  is  known  that  benchmark  performance  will  be  difficult  to  achieve  if  the  combined  effects  of  interpolation  and  anti¬ 
alias  filter  produce  more  than  .04  dB  excess  attenuation  at  0.0833  times  the  input  sample  rate  and  more  than  1.6  dB 
of  additional  attenuation  at  0. 166  times  the  sample  rate  where  the  input  sample  rate  is  referred  to  the  input  of  the 
interpolator  assuming  6  samples  per  second. 
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23.3.2  Characteristics  of  SOQPSK-TG 

The  SOQPSK  method  is  a  family  of  constant-envelope  CPM  waveforms.  It  is 

most  simply  described  as  a  non-linear  FM  modeled  as  shown  in  Figure  2-2. 


Impulse  Series 


S(t) 


Figure  2-2.  Basic  SOQPSK 


The  SOQPSK  waveform  family  is  uniquely  defined  in  terms  of  impulse  excitation  of  a 
frequency  impulse  shaping  filter  function  g(t): 


g  (/)  =  n(t)w(t) 


(2-5) 


where 


0,(1) 

0,(1) 


A  cos  frO^(l) 

sin  0,  (I ) 

- 1 

_ 1 

0,(0  _ 

pBt 

nBt 


(2-6) 


T.  J.  Hill.  “An  Enhanced,  Constant  Envelope,  Interoperable  Shaped  Offset  QPSK  (SOQPSK)  Waveform  for 
Improved  Spectral  Efficiency.”  Paper  presented  during  36th  Annual  International  Telemetering  Conference,  San 
Diego,  CA.  October  23-26,  2000. 

"  Younes  B.,  James  Erase,  Chitra  Patel,  and  John  Wesdock.  “An  Assessment  of  Shaped  Offset  QPSK  for  Use  in 
NASA  Space  Network  and  Ground  Network  Systems”  in  Proceedings  of  the  CCSDS  RF  and  Modulation  Subpanel 
IE  Meeting  of  May  2001  Concerning  Bandwidth-Efficient  Modulation.  CCSDS  B20.0-Y-2.  June  2001.  Retrieved 
4  June  2015.  Available  at  http://public.ccsds.org/publications/archive/B20x0v2.pdf. 

Mark  Geoghegan.  “Implementation  and  Performance  Results  for  Trellis  Detection  of  SOQPSK.”  Paper  presented 
at  the  37*  Annual  International  Telemetering  Conference,  Las  Vegas,  NV,  October  2001. 

Marvin  Simon.  “Bandwidth-Efficient  Digital  Modulation  with  Application  to  Deep  Space  Communications.” 

JPL  Publication  00-17.  June  2001.  Retrieved  3  June  2015.  Available  at 
http://descanso.ipl.nasa.gov/monograph/series3/completel.pdf. 
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1, 


<z 


w(t)  = 


-I- cos 


/ 

t 

\ 

n 

T 

-T, 

V 

/ 

T 
^  2 


T,< 


<T,+T, 


(2-7) 


0, 


>  7)  -h  T) 


The  function  n(t)  is  a  modified  spectral  raised  cosine  filter  of  amplitude  A,  rolloff  factor 
p,  and  an  additional  time  scaling  factor  B.  The  function  w(t)  is  a  time  domain  windowing 
function  that  limits  the  duration  of  g(t).  The  amplitude  scale  factor  A  is  chosen  such  that 


(Ti+T)/; 

J  g(l)dl  =  Y 

-(r, +7-2)7; 


(2-8) 


Given  a  time  series  binary  data  sequence 

a  =  (. . .  ,(T_2 , 6/_| ,  ,  (7, ,  <7, . . . )  (2-9) 

wherein  the  bits  are  represented  by  normalized  antipodal  amplitudes  {+1,-1},  the  ternary 
impulse  series  is  formed  with  the  following  mapping  rule  (see  also  Geoghegan,  Implementation 
and  Simon,  Bandwidth),  . . . 

a  =  1)'"'  1  ~  2  )  (2-10) 

that  will  form  a  data  sequence  alphabet  of  three  values  {+1,0,-!}.  It  is  important  to  note  that  this 
modulation  definition  does  not  establish  an  absolute  relationship  between  the  digital  in-band 
inter-switch  trunk  signaling  (dibits)  of  the  binary  data  alphabet  and  transmitted  phase  as  with 
conventional  quadriphase  offset  quadrature  phase  shift  keying  (OQPSK)  implementations.  In 
order  to  achieve  interoperability  with  coherent  FQPSK-B  demodulators,  some  form  of  precoding 
must  be  applied  to  the  data  stream  prior  to,  or  in  conjunction  with,  conversion  to  the  ternary 
excitation  alphabet.  The  differential  encoder  defined  in  Subsection  2. 3. 3. 1.1  fulfills  this  need; 
however,  to  guarantee  full  interoperability  with  the  other  waveform  options,  the  polarity 
relationship  between  frequency  impulses  and  resulting  frequency  or  phase  change  must  be 
controlled.  Thus,  SOQPSK  modulators  proposed  for  this  application  shall  guarantee  that  an 
impulse  value  of  (+1)  will  result  in  an  advancement  of  the  transmitted  phase  relative  to  that  of 
the  nominal  carrier  frequency  (i.e.,  the  instantaneous  frequency  is  above  the  nominal  carrier). 

For  purposes  of  this  standard,  only  one  specific  variant  of  SOQPSK  and  SOQPSK-TG  is 
acceptable.  This  variant  is  defined  by  the  parameter  values  given  in  Table  2-4. 
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Table  2-4. 

SOQPSK-TG  Parameters 

SOQPSK  Type 

P 

B 

Ti 

T2 

SOQPSK-TG 

0.70 

1.25 

1.5 

0.50 

As  discussed  above,  interoperability  with  FQPSK-B  equipment  requires  a  particular  pre¬ 
coding  protocol  or  a  functional  equivalent  thereof.  A  representative  model  is  shown  in  Figure 


2-3. 


Impulse  Series 


{a  (nT) } 


Figure  2-3.  SOQPSK  Transmitter 


The  differential  encoder  block  will  be  implemented  in  accordance  with  the  definition  of 
Subsection  2. 3. 3. 1.1.  Given  the  symbol  sequences  h  and  Qk,  and  the  proviso  that  a  normalized 
impulse  sign  of  -i-l  will  increase  frequency,  the  pre-coder  will  provide  interoperability  with  the 
FQPSK  signals  defined  herein  if  code  symbols  are  mapped  to  frequency  impulses  in  accordance 
with  Table  2-5  where  AO  is  the  phase  change. 


Table  2-5.  SOQPSK  Pre-Coding  Table  for  IRIG-106  Compatibility 

Ma 

p  ttK  from  Ik 

Map  ttK+i  from  Qk+\ 

/k 

Qk-l 

Ik-2 

AO 

ttk 

Qk+l 

Ik 

Qk-l 

AO 

ak+1 

-1 

X* 

-1 

0 

0 

-1 

X* 

-1 

0 

0 

-1-1 

X* 

-1-1 

0 

0 

-1-1 

X* 

-1-1 

0 

0 

-1 

-1 

-1-1 

-n/2 

-1 

-1 

-1 

-1-1 

+7i/2 

-1-1 

-1 

-1-1 

-1-1 

+7i/2 

-1-1 

-1 

-1-1 

-1-1 

-7i/2 

-1 

+\ 

-1 

-1 

+7i/2 

-1-1 

-1-1 

-1 

-1 

-7i/2 

-1 

-1-1 

-1-1 

-1 

-7i/2 

-1 

-1-1 

-1-1 

-1 

+7i/2 

-1-1 

*  Note:  Does  not  matter  if  “X”  is  a  +1  or  a  -1 

2. 3. 3. 3  Characteristics  of  Advanced  Range  Telemetry  Continuous  Phase  Modulation 

The  ARTM  CPM  is  a  quaternary  signaling  scheme  in  which  the  instantaneous  frequency 
of  the  modulated  signal  is  a  function  of  the  source  data  stream.  The  frequency  pulses  are  shaped 
for  spectral  containment  purposes.  The  modulation  index  alternates  at  the  symbol  rate  between 
two  values  to  improve  the  likelihood  that  the  transmitted  data  is  faithfully  recovered.  Although 
the  following  description  is  in  terms  of  carrier  frequency,  other  representations  and  generation 
methods  exist  that  are  equivalent.  A  block  diagram  of  a  conceptual  ARTM  CPM  modulator  is 
illustrated  in  Figure  2-4.  Source  bits  are  presented  to  the  modulator  and  are  mapped  into 
impulses  that  are  applied  to  a  filter  with  an  impulse  response  g(t).  The  resulting  waveform  f(t)  is 
proportional  to  the  instantaneous  frequency  of  the  desired  modulator  output.  This  signal  can  be 
used  to  frequency  modulate  a  carrier  to  produce  an  RF  signal  representation. 
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Figure  2-4.  Conceptual  CPM  Modulator 


Variables  and  function  definitions  in  Figure  2-4  are  as  follows. 

•  a(iT/2)  =  ith  bit  of  binary  source  data,  either  a  0  or  1 . 

•  The  frequency  pulse  shape  for  ARTM  CPM  is  a  three- symbol-long  raised  cosine 


pulse  defined  by  the  following  equation  for  0  <  t  <3T, 


1-cos 


iTlt 

3T 


(2-11) 


T  =  Symbol  period  equal  to  2/(bit  rate  in  bits/second). 

a(iT)  =  ith  impulse  with  area  equal  to  either  a  +3,  +1,  -1,  or  -3  determined  by  Table 
2-6.  Note  that  an  impulse  is  generated  for  each  dibit  pair  (at  the  symbol  rate). 


Table  2-6.  Dibit  to  Impulse  Area  Mapping 

Input  Dibit  [a(i)  a(i-i-l)] 

Impulse  Area 

I  I 

-f3 

1  0 

-i-I 

0  I 

-1 

00 

-3 

•  f(t,  a)  =  frequency  filter  output  equal  to  the  following  equation. 


+00 

7rhi'^a{iT)g{t -iT)  (2-12) 

i=-oo 


•  h  =  modulation  index;  h  alternates  between  hi  and  h2  where  hi  =  4/16,  hi  =  5/16. 

For  more  information  on  the  ARTM  CPM  waveform,  please  refer  to  0  and  to 
Geoghegan’s  paper. 

2. 3. 3.4  Data  Randomization 

The  data  input  to  the  transmitter  shall  be  randomized  using  either  an  encryptor  that 
provides  randomization  or  an  Inter-Range  Instrumentation  Group  (IRIG)  15-bit  randomizer  as 


Mark  Geoghegan.  “Description  and  Performance  Results  for  the  Multi-h  CPM  Tier  II  Waveform.”  Paper 
presented  at  the  36*  International  Telemetering  Conference,  San  Diego,  CA,  October  2000. 
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described  in  Chapter  6  and  Annex  A.2.  The  purpose  of  the  randomizer  is  to  prevent  degenerative 
data  patterns  from  degrading  data  quality. 

2. 3. 3. 5  Bit  Rate 

The  bit  rate  range  for  FQPSK-B,  FQPSK-JR,  and  SOQPSK-TG  shall  be  between  1 
megabit  per  second  (Mbps)  and  20  Mbps.  The  bit  rate  range  for  ARTM  CPM  shall  be  between  5 
Mbps  and  20  Mbps. 

2. 3. 3. 6  Transmitter  Phase  Noise 

The  sum  of  all  discrete  spurious  spectral  components  (single-sideband)  shall  be  less  than 
-36  dBc.  The  continuous  single-sideband  phase  noise  power  spectral  density  (PSD)  shall  be 
below  the  curve  shown  in  Figure  2-5.  The  maximum  frequency  for  the  curve  is  one-fourth  of  the 
bit  rate.  For  bit  rates  greater  than  4  Mbps,  the  phase  noise  PSD  shall  be  less  than  -100  dBc/hertz 
(Hz)  between  1  MHz  and  one-fourth  of  the  bit  rate. 


233.1  Modulation  Polarity 

An  increasing  voltage  at  the  input  of  an  FM  transmitter  shall  cause  an  increase  in  output 
carrier  frequency.  An  increase  in  voltage  at  the  input  of  a  PM  transmitter  shall  cause  an 
advancement  in  the  phase  of  the  output  carrier.  An  increase  in  voltage  at  the  input  of  an 
amplitude  modulation  (AM)  transmitter  shall  cause  an  increase  in  the  output  voltage  of  the 
output  carrier. 
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2.3.4  Spurious  Emission  and  Interference  Limits 

Spurious  emissions  from  the  transmitter  ease,  through  input  and  power  leads,  and  at  the 
transmitter  RF  output  and  antenna-radiated  spurious  emissions  are  to  be  within  required  limits 
shown  in  Military  Standard  (MIL-STD)-461.*®  Other  applicable  standards  and  specifications 
may  be  used  in  place  of  MIL-STD-461  if  necessary. 


2.3.4. 1  Transmitter- Antenna  System  Emissions 

Emissions  from  the  antenna  are  of  primary  importance.  Eor  example,  a  tuned  antenna 
may  or  may  not  attenuate  spurious  frequency  products  produced  by  the  transmitter,  and  an 
antenna  or  multi-transmitter  system  may  generate  spurious  outputs  when  a  pure  signal  is  fed  to 
its  input.  The  transmitting  pattern  of  such  spurious  frequencies  is  generally  different  from  the 
pattern  at  the  desired  frequency.  Spurious  outputs  in  the  transmitter  output  line  shall  be  limited 
to  -25  dBm.  Antenna-radiated  spurious  outputs  shall  be  no  greater  than  320  pV/meter  at  30 
meters  in  any  direction. 


WARNING 


Spurious  levels  of -25  dBm  may  severely  degrade  performance  of  sensitive 
receivers  whose  antennas  are  located  in  close  proximity  to  the  telemetry 
transmitting  antenna.  Therefore,  lower  spurious  levels  may  be  required  in 
certain  frequency  ranges,  such  as  near  Global  Positioning  System 
frequencies. 


2 . 3 . 4 . 2  Conducted  and  Radiated  Interference 

Interference  (and  the  RE  output  itself)  radiated  from  the  transmitter  or  fed  back  into  the 
transmitter  power,  signal,  or  control  leads  could  interfere  with  the  normal  operation  of  the 
transmitter  or  the  antenna  system  to  which  the  transmitter  is  connected.  All  signals  conducted  by 
the  transmitter's  leads  (other  than  the  RE  output  cable)  in  the  range  of  150  kilohertz  (kHz)  to  50 
MHz  and  all  radiated  fields  in  the  range  of  150  kHz  to  10  gigahertz  (GHz)  (or  other  frequency 
ranges  as  specified)  must  be  within  the  limits  of  the  applicable  standards  or  specifications. 

2.3.5  Operational  Elexibility 

Each  transmitter  shall  be  capable  of  operating  at  all  frequencies  within  its  allocated  band 
without  design  modification.*’ 

2.3.6  Modulated  Transmitter  Bandwidth— 

Telemetry  applications  covered  by  this  standard  shall  use  99-percent  power  bandwidth  to 
define  occupied  bandwidth  and  -25  dBm  bandwidth  as  the  primary  measure  of  spectral 
efficiency.  The  -25  dBm  bandwidth  is  the  minimum  bandwidth  that  contains  all  spectral 
components  that  are  -25  dBm  or  larger.  A  power  level  of -25  dBm  is  exactly  equivalent  to  an 
attenuation  of  the  transmitter  power  by  55  -i-  lOxlog(P)  dB  where  P  is  the  transmitter  power 
expressed  in  watts.  The  spectra  are  assumed  symmetrical  about  the  transmitter’s  center 


Any  unwanted  signal  or  emission  is  spurious  whether  or  not  it  is  related  to  the  transmitter  frequency  (harmonic). 

Department  of  Defense.  “Requirements  for  the  Control  of  Electromagnetic  Interference  Characteristics  of 
Subsystems  and  Equipment.”  MIL-STD-461.  1 1  December  2015.  May  be  superseded  by  update.  Retrieved  23 
March  2017.  Available  at  http ://quicksearch. dla.mil/asDocDetails. ast)x?ident  number=35789. 

The  intent  is  that  fixed-frequency  transmitters  can  be  used  at  different  frequencies  by  changing  crystals  or  other 
components.  All  applicable  performance  requirements  will  be  met  after  component  change. 

These  bandwidths  are  measured  using  a  spectrum  analyzer  with  the  following  settings:  30-kHz  resolution 
bandwidth,  300-Hz  video  bandwidth,  and  no  max  hold  detector  or  averaging. 
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frequency  unless  specified  otherwise.  All  spectral  components  larger  than  -(55  +  lOxlog(P)) 
dBc  at  the  transmitter  output  must  be  within  the  spectral  mask  calculated  using  the  following 
equation: 

m(/)  =  iT  +  90  log  A  - 100  logl/ - /cl ;  1/ - /cl  > - 

m  (2-13) 

where  M(f)  =  power  relative  to  P  (i.e.,  units  of  dBc)  at  frequency  f  (MHz) 

K  =  -20  for  analog  signals 
=  -28  for  binary  signals 
=  -61  for  FQPSK-B,  FQPSK-JR,  SOQPSK-TG 
=  -73  for  ARTM  CPM 
fc  =  transmitter  center  frequency  (MHz) 

R  =  bit  rate  (Mbps)  for  digital  signals  or  (Af+fmax)  (MHz)  for  analog  FM  signals 
m  =  number  of  states  in  modulating  signal; 
m  =  2  for  binary  signals 
m  =  4  for  quaternary  signals  and  analog  signals 

^  f  =  peak  deviation 

fmax  =  maximum  modulation  frequency 

Note  that  the  mask  in  this  standard  is  different  than  the  masks  contained  in  earlier 
versions  of  the  Telemetry  Standards.  Equation  2-13  does  not  apply  to  spectral  components 
separated  from  the  center  frequency  by  less  than  R/m.  The  -25  dBm  bandwidth  is  not  required 
to  be  narrower  than  1  MHz.  Binary  signals  include  all  modulation  signals  with  two  states  while 
quaternary  signals  include  all  modulation  signals  with  four  states  (quadrature  phase  shift  keying 
[QPSK]  and  FQPSK-B  are  two  examples  of  four-state  signals).  Section  A. 6  contains  additional 
discussion  and  examples  of  this  spectral  mask. 

2.3.7  Valid  Center  Frequencies  Near  Telemetry  Band  Edges 

The  telemetry  bands,  as  specified,  start  and  stop  at  discrete  frequencies.  Telemetry 
transmitters  transmitting  PCM/FM  or  SOQPSK-TG/FQPSK-B/FQPSK-JR  or  ARTM  CPM,  even 
with  optimal  filtering,  do  not  have  discrete  start  and  stop  frequencies.  In  order  to  determine  a 
valid  carrier  frequency,  the  transmitter  power,  modulation  scheme,  and  data  rate  must  be  known. 
The  distance,  in  frequency,  from  the  point  in  which  the  spectral  masks,  as  described  in 
Subsection  2.3.6,  intersect  the  absolute  value  of -25  dBm  equals  the  amount  in  which  the 
transmitter  carrier  frequency  must  be  from  the  band  edge  frequency.  Subsection  A. 12  contains 
additional  discussion  and  examples  of  center  frequency  determination  when  operating  near 
telemetry  band  edges. 

2.4  Telemetry  Receiver  Systems 

As  a  minimum,  receiver  systems  shall  have  the  following  characteristics. 

2.4.1  Spurious  Emissions 

The  RE  energy  radiated  from  the  receiver  itself  or  fed  back  into  the  power  supply,  and/or 
the  RE  input,  output,  and  control  leads  in  the  range  from  150  kHz  to  10  GHz  shall  be  within  the 
limits  specified  in  MIE-STD-461.  The  receiver  shall  be  tested  in  accordance  with  MIE-STD-461 
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or  RCC  Document  118,  Volume  II.  Other  applicable  standards  and  specifications  may  be  used 
in  place  of  MIL-STD-461,  if  necessary. 

2.4.2  Frequency  Tolerance 

The  accuracy  of  all  local  oscillators  within  the  receiver  shall  be  such  that  the  conversion 
accuracy  at  each  stage  and  overall  is  within  +0.001  percent  of  the  indicated  tuned  frequency 
under  all  operating  conditions  for  which  the  receiver  is  specified. 

2.4.3  Receiver  Phase  Noise 

The  sum  of  all  discrete  spurious  spectral  components  (single-sideband)  shall  be  less  than 
-39  dBc.  The  continuous  single-sideband  phase  noise  PSD  shall  be  3  dB  below  the  curve  shown 
in  Figure  2-5.  The  maximum  frequency  for  the  curve  in  Figure  2-5  is  one-fourth  of  the  bit  rate. 
For  bit  rates  greater  than  4  Mbps,  the  phase  noise  PSD  shall  be  less  than  -103  dBc/Hz  between  1 
MHz  and  one-fourth  of  the  bit  rate. 

2.4.4  Spurious  Responses 

Rejection  of  any  frequency  other  than  the  one  to  which  the  receiver  is  tuned  shall  be  a 
minimum  of  60  dB  referenced  to  the  desired  signal  over  the  range  150  kHz  to  10  GHz. 

2.4.5  Operational  Flexibility 

All  ground-based  receivers  shall  be  capable  of  operating  over  the  entire  band  for  which 
they  are  designed.  External  down-converters  may  be  either  intended  for  the  entire  band  or  a 
small  portion  but  capable  of  retuning  anywhere  in  the  band  without  modification. 

2.4.6  Intermediate  Frequency  Bandwidths 

The  standard  receiver  intermediate  frequency  (IF)  bandwidths  are  shown  in  Table  2-7. 
These  bandwidths  are  separate  from  and  should  not  be  confused  with  post-detection  low-pass 
filtering  that  receivers  provide. The  ratio  of  the  receiver’s  -60  dB  bandwidth  to  the  -3  dB 
bandwidth  shall  be  less  than  3  for  new  receiver  designs. 


Table  2-7.  Standard  Receiver  Intermediate 

Frequency  Bandwidths 

300  kHz 

1.5  MHz 

6  MHz 

500  kHz 

2.4  MHz 

10  MHz 

750  kHz 

3.3  MHz 

15  MHz 

1000  kHz 

4.0  MHz 

20  MHz 

NOTE 


For  data  receivers,  the  IF  bandwidth  should  typically  be  selected  so  that  90 
to  99  percent  of  the  transmitted  spectrum  is  within  the  receiver  3  dB 
bandwidth.  In  most  cases,  the  optimum  IF  bandwidth  will  be  narrower 
than  the  99  percent  power  bandwidth. 


Range  Commanders  Council.  Test  Methods  for  Telemetry  Systems  and  Subsystems  Volume  2.  RCC  118-12.  May 
be  superseded  by  update.  Retrieved  4  June  2015.  Available  at 

httr)://www.wsmr.armv.mil/RCCsite/Documents/l  18-12  Vol  2-Test  Methods  for  Telemetry  RF  Subsystems/. 

In  most  instances,  the  output  low-pass  filter  should  not  be  used  to  “clean  up”  the  receiver  output  prior  to  use  with 
demultiplexing  equipment. 
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2.  Bandwidths  are  expressed  at  the  points  where  response  is  3  dB  below  the 
response  at  the  design  center  frequency,  assuming  that  passband  ripple  is 
minimal,  which  may  not  be  the  case.  The  3-dB  bandwidth  is  chosen 
because  it  closely  matches  the  noise  bandwidth  of  a  “brick-wall”  filter  of 
the  same  bandwidth.  The  “optimum”  bandwidth  for  a  specific  application 
may  be  other  than  that  stated  here.  Ideal  IF  filter  response  is  symmetrical 
about  its  center  frequency;  in  practice,  this  may  not  be  the  case. 

3.  Not  all  bandwidths  are  available  on  all  receivers  or  at  all  test  ranges. 
Additional  receiver  bandwidths  may  be  available  at  some  test  ranges, 
especially  if  the  range  has  receivers  with  digital  IF  filtering 


2.4.7  C-band  Downconversion 

For  telemetry  receive  systems  employing  C-band  downconversion,  the  following 
mapping  of  C-band  RF  to  C-band  IF  frequencies  is  recommended  for  the  lower  C  and  middle  C 
bands.  This  downconversion  scheme  utilizes  a  high-side  local  oscillator  frequency  of  5550  MHz 
to  minimize  the  potential  of  mixing  products  interfering  with  received  telemetry  signals. 
Additionally,  using  a  standardized  approach  fosters  interoperability  between  manufacturers  of 
telemetry  antenna  systems  employing  downconversion  and  manufacturers  of  telemetry  receivers 
with  C-IF  tuners. 

No  recommendation  will  be  made  at  this  point  for  the  downconversion  of  the  upper  C 
band  (5925-6700  MHz). 

Examples: 

C-IF  Frequency  =  (5550  MHz  -  C-RF  Frequency) 

1 150  MHz  =  (5550  MHz  -  4400  MHz) 

610  MHz  =  (5550  MHz  -  4940  MHz) 

459  MHz  =  (5550  MHz  -  5091  MHz) 

400  MHz  =  (5550  MHz  -  5150  MHz) 

2.5  Codes  for  Telemetry  Systems 

2.5.1  Low-Density  Parity-Check  Code 

Forward  error  correction  (FEC)  is  a  way  of  adding  additional  information  to  a  transmitted 
bit  stream  in  order  to  decrease  the  required  signal-to-noise  ratio  to  the  receiver  for  a  given  bit 
error  rate  (BER).  Eow-density  parity-check  (EDPC)  code  is  a  block  code,  meaning  that  a  block 
of  information  bits  has  parity  added  to  them  in  order  to  correct  for  errors  in  the  information  bits. 
The  term  “low-density”  stems  from  the  parity  check  matrix  containing  mostly  O’s  and  relatively 
few  I’s.  This  specific  EDPC  variant  comes  from  the  satellite  link  community  and  is  identical  to 
the  Accumulate-Repeat-4- Jagged- Accumulate  code  described  by  the  Consultative  Committee  for 
Space  Data  Systems  (CCSDS)  standard  131.1-0-2-S.l,^*  which  describes  nine  different  EDPC 
codes  with  different  coding  rates  (rate  1/2,  2/3,  4/5)  and  information  block  sizes  (1024,  4096, 
16384).  In  the  trade  between  the  transmission  channel  characteristics,  bandwidth  efficiency. 


Consultative  Committee  for  Space  Data  Systems.  Low  Density  Parity  Check  Codes  for  Use  in  Near-Earth  and 
Deep  Space  Applications.  Standard  CCSDS  131. 1-0-2-S.  September  2007.  Rescinded.  Retrieved  30  June  2015. 
Available  at  http://public.ccsds.org/publications/archive/131xlo2e2s.pdf. 
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coding  gain,  and  block  size  all  three  rates  and  block  sizes  1024  and  4096  are  considered  in  this 
standard.  Additional  information  on  this  LDPC  code  is  contained  in  Appendix  2-D. 

2.5.2  Space-Time  Code 

As  the  name  suggests,  this  code  uses  space  diversity  and  time  diversity  to  overcome  the 
two-antenna  problem,  which  is  characterized  by  large  variances  in  the  antenna  gain  pattern  from 
a  test  article  caused  by  transmitting  the  same  telemetry  signal  time  through  two  transmit 
antennas.  These  signals  are  typically  delayed  in  time  and  have  differing  amplitudes.  The  space- 
time  code  (STC)  in  this  standard  applies  to  only  SOQPSK-TG  modulation.  The  input  bit  stream 
is  space-time  coded,  resulting  in  two  parallel  bit  streams  that  then  have  a  pilot  sequence  added  to 
each  at  fixed  bit  intervals  (or  blocks).  These  encoded/pilot-added  streams  are  then  individually 
modulated  through  phase-locked  transmitters  to  a  carrier  using  SOQPSK-TG  modulation,  power 
amplified,  then  connected  to  a  top  and  bottom  antenna.  The  job  of  estimating  frequency  offset, 
delays,  gains,  and  phase  shifts  due  to  the  transmission  channel  then  space-time  decode  the  signal 
is  done  with  the  STC  receiver.  Additional  information  on  the  STC  is  contained  in  Appendix  2-E. 

2.6  Randomization  Methods  for  Telemetry  Systems 

2.6.1  Introduction 

The  following  randomization  and  de-randomization  methods  are  recommended  for 
wireless  serial  streaming  telemetry  data  links.  The  choice  of  randomization  method  used  should 
be  based  on  whether  or  not  a  self-synchronizing  randomizer  is  required  for  the  application. 

2.6.2  Randomizer  Types 

2.6.2. 1  Self-Synchronizing  Randomizers 

Self-synchronizing  randomizers,  such  as  the  traditional  IRIG  randomizer  described  in 
Annex  A. 2,  work  best  when  there  are  no  known  identifiers  in  the  bit  stream  to  aid  in 
synchronizing  the  de-randomizer.  This  type  of  de-randomizer  has  the  characteristic  of  creating 
additional  bit  errors  when  a  bit  error  is  received  at  the  de-randomizer  input.  For  this  randomizer 
a  single  bit  error  at  the  input  will  create  an  additional  two  bit  errors  in  the  output  stream.  This 
BER  extension  will  cause  a  degradation  in  detection  efficiency  of  the  link  of  approximately  0.5 
dB. 

2. 6. 2. 2  Non-Self-Synchronizing  Randomizers 

Non-self-synchronizing  randomizers,  such  as  the  CCSDS  randomizer  described  in 
Appendix  2-D,  do  not  create  additional  bit  errors  when  a  bit  error  is  received  at  the  de¬ 
randomizer  input.  Therefore  there  is  no  extension  of  BER;  however,  these  types  of  randomizers 
need  to  be  synchronized  with  the  incoming  bit  stream.  This  is  usually  accomplished  through  the 
use  of  pilot  bits  or  synchronization  markers  in  the  data  stream  to  aid  in  synchronization. 
Performance  of  this  type  of  randomizer  will  exceed  that  of  a  self-synchronizing  randomizer 
lending  itself  as  a  better  choice  for  coded  links  or  links  requiring  data-aided  synchronization. 

2.6.3  Randomizer  Application 

As  defined  in  Appendix  2-D,  CCSDS  randomization  as  defined  in  should  be  used  for 
coded  links  such  as  EDPC  links  or  links  exhibiting  a  block  structure  with  synchronization 
markers. 
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Traditional  IRIG  randomization  as  defined  in  Annex  A. 2  should  be  used  for  non- 
encrypted  links  that  are  absent  of  synchronization  markers  or  do  not  contain  markers  of  any  type. 
Encrypted  telemetry  links  do  not  require  randomization. 

2.7  Data  Quality  Metrics  and  Data  Quality  Encapsulation 

A  reliable  metric  for  estimating  data  quality  can  be  very  useful  when  controlling 
telemetry  data  processing  equipment,  such  as  Best  Source  Selectors,  that  require  an 
understanding  of  received  data  quality  in  order  to  operate  effectively.  To  accomplish  this,  a 
standardized  method  for  estimating  bit  error  probability  (BEP)  is  needed.  In  addition  to  the 
metric,  a  standardized  method  for  transporting  the  metric  with  the  associated  data  is  required. 
Appendix  2-G  provides  a  standard  for  a  Data  Quality  Metric  (DQM),  determined  in  the  telemetry 
receiver  demodulator,  and  a  standard  for  Data  Quality  Encapsulation  (DQE)  allowing  for 
transport  of  the  received  telemetry  data  and  associated  DQM. 

2.8  Interference  Protection  Criteria  for  Aeronautical  Mobile  Telemetry  Systems 

Aeronautical  mobile  telemetry  (AMT)  ground  stations  use  very  high  gain  directional 
antenna  systems  that  are  sensitive  to  interference  from  other  RE  communication  systems. 

Without  appropriate  interference  protection,  these  systems  could  be  severely  impacted  or  even 
rendered  useless  for  mission  support.  To  prevent  this  from  happening,  appropriate  interference 
protection  criteria  (IPC)  are  needed. 

Table  2-8  lists  the  acceptable  power  flux  density  (PED)  levels  for  interference  in  each 
telemetry  band.  These  levels  are  based  on  the  well-established  and  accepted  IPC  contained  in 
International  Telecommunications  Union  Radio  Service  (ITU-R)  Recommendation  M.1459^^ 
(Rec  M.1459).  These  IPCs  provide  AMT  protection  for  aggregate  interference  from  satellites 
and  terrestrial  emitters  as  a  function  of  the  angle  of  arrival  a  of  the  interfering  signal(s)  at  or 
above  the  horizon  derived  using  the  methodology  given  in  Annex  A  of  Rec  M.  1459. 


Table  2-8.  Interference  Protection  Criteria  by  Band  and  Angle  of  Arrival 

L  band,  from  1435  -  1535  MHz 

-181.0 

dB(W/m^)  in  4  kHz 

for  0  <  a  <  4° 

-193.0  +  20  log  a 

dB(W/m^)  in  4  kHz 

for  4  <  a  <  20° 

-213.3  +  35.6  log  a 

dB(W/m^)  in  4  kHz 

for  20  <  a  <  60° 

-150.0 

dB(W/m^)  in  4  kHz 

for  60  <  a  <  90° 

Upper  L  band,  from  1755  -  1855  MHz 

-181.0 

dB(W/m^)  in  4  kHz 

for  0°  <  a  <  3° 

-190.878  +  21.948  logo 

dB(W/m^)  in  4  kHz 

for  3°  <  a  <  15° 

-185.722+  18.286  logo 

dB(W/m^)  in  4  kHz 

for  15°  <  a  <  60° 

-153.7 

dB(W/m^)  in  4  kHz 

for  60°  <  a  <  90° 

Lower  S  band,  from  2200  -  2290  MHz 

-180.0 

dB(W/mQ  in  4  kHz 

for  0°  <  a  <  2° 

International  Telecommunication  Union.  “Protection  criteria  for  telemetry  systems  in  the  aeronautical  mobile 
service...”  ITU-R  Recommendation  M.1459.  May  2000.  May  be  superseded  by  update.  Available  at 
https://www.itu.int/rec/R-REC-M.1459-0-200005-I/en. 
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Table  2-8.  Interference  Protection  Criteria  by  Band  and  Angle  of  Arrival 

-186.613  +  21.206  log  a 

dB(W/m"^)  in  4  kHz 

for2°<a<  15° 

-161 

dB(W/m^)  in  4  kHz 

for  15°  <  a  <  90° 

Upper  S  band,  from  2310  -  2390  MHz 

-180.0 

dB(W/m^)  in  4  kHz 

for  0°  <  a  <  2° 

-187.5  +  23.66  log  a 

dB(W/m^)  in  4  kHz 

for2°<a<  11.5° 

-162 

dB(W/m^)  in  4  kHz 

for  11.5°<a<90° 

Lower  C  band,  from  4400  -  4940  MHz 

-178.0 

dB(W/m^)  in  4  kHz 

for  0°  <  a  <  1° 

-180.333  +  2.333  a 

dB(W/m^)  in  4  kHz 

for  1°  <  a  <  4° 

-171.0 

dB(W/m^)  in  4  kHz 

for  4°  <  a  <  90° 

Middle  C  band,  from  5091  -  5150  MHz 

-178.0 

dB(W/m^)  in  4  kHz 

for  0°  <  a  <  1° 

-180.0  +  2.0  a 

dB(W/m^)  in  4  kHz 

for  1°  <  a  <  3° 

-174.0 

dB(W/m^)  in  4  kHz 

for  3°  <  a  <  90° 

Upper  C  band,  from  5925  -  6700  MHz 

-178.0 

dB(W/m^)  in  4  kHz 

for  0°  <  a  <  1° 

-181.6  +  3.6a 

dB(W/m^)  in  4  kHz 

for  1°  <  a  <  2° 

-174.4 

dB(W/m^)  in  4  kHz 

for  2°  <  a  <  90° 

Appendix  2-F  provides  additional  explanation  and  example  ealculations  to  aid  in 
understand  the  applieation  of  these  IPCs  for  different  interferenee  seenarios. 
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APPENDIX  2-A 

Frequency  Considerations  for  Telemetry 


A.l.  Purpose 

This  appendix  was  prepared  with  the  cooperation  and  assistance  of  the  Range 
Commanders  Council  (RCC)  Frequency  Management  Group.  This  appendix  provides  guidance 
to  telemetry  users  for  the  most  effective  use  of  the  telemetry  bands.  Coordination  with  the 
frequency  managers  of  the  applicable  test  ranges  and  operating  areas  is  recommended  before  a 
specific  frequency  band  is  selected  for  a  given  application.  Government  users  should  coordinate 
with  the  appropriate  Area  Frequency  Coordinator  and  commercial  users  should  coordinate  with 
the  AFTRCC.  A  list  of  the  points  of  contact  can  be  found  in  the  NTIA  manual  (NTIA  2015). 

A.2.  Scope 

This  appendix  is  to  be  used  as  a  guide  by  users  of  telemetry  frequencies  at  Department  of 
Defense  (DoD)-related  test  ranges  and  contractor  facilities.  The  goal  of  frequency  management 
is  to  encourage  maximal  use  and  minimal  interference  among  telemetry  users  and  between 
telemetry  users  and  other  users  of  the  electromagnetic  spectrum. 

A. 2. a.  Definitions 

The  following  terminology  is  used  in  this  appendix. 

Allocation  (of  a  Frequency  Band).  Entry  of  a  frequency  band  into  the  Table  of  Frequency 
Allocations^^  for  use  by  one  or  more  radio  communication  services  or  the  radio  astronomy 
service  under  specified  conditions. 

Assignment  (of  a  Radio  Frequency  or  Radio  Frequency  Channel).  Authorization  given  by  an 
administration  for  a  radio  station  to  use  an  RF  or  RF  channel  under  specified  conditions. 

Authorization.  Permission  to  use  an  RF  or  RF  channel  under  specified  conditions. 

Certification.  The  Military  Communications  -  Electronics  Board’s  (MCEB)  process  of 
verifying  that  a  proposed  system  complies  with  the  appropriate  rules,  regulations,  and  technical 
standards. 

J/F  12  Number.  The  identification  number  assigned  to  a  system  by  the  MCEB  after  the 
Application  for  Equipment  Erequency  Allocation  (DD  Eorm  1494)  is  approved;  for  example,  J/E 
12/6309  (sometimes  called  the  J-12  number). 

Resolution  Bandwidth.  The  -3  dB  bandwidth  of  the  measurement  device. 

A.2.b.  Modulation  methods 

A.2.b(l)  Traditional  Modulation  Methods 

The  traditional  modulation  methods  for  aeronautical  telemetry  are  EM  and  PM.  The 
PCM/EM  method  has  been  the  most  popular  telemetry  modulation  since  around  1970.  The 


The  definitions  of  the  radio  services  that  can  be  operated  within  certain  frequency  bands  contained  in  the  radio 
regulations  as  agreed  to  by  the  member  nations  of  the  International  Telecommunications  Union.  This  table  is 
maintained  in  the  United  States  by  the  Federal  Communications  Commission  and  the  NTIA. 
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PCM/FM  method  could  also  be  called  filtered  CPFSK.  The  RF  signal  is  typically  generated  by 
filtering  the  baseband  NRZ-L  signal  and  then  frequency  modulating  a  VCO.  The  optimum  peak 
deviation  is  0.35  times  the  bit  rate  and  a  good  choice  for  a  premodulation  filter  is  a  multi-pole 
linear  phase  filter  with  bandwidth  equal  to  0.7  times  the  bit  rate.  Both  FM  and  PM  have  a 
variety  of  desirable  features  but  may  not  provide  the  required  bandwidth  efficiency,  especially 
for  higher  bit  rates. 

A.2.b(2)  Improved  Bandwidth  Efficiency 

When  better  bandwidth  efficiency  is  required,  the  standard  methods  for  digital  signal 
transmission  are  the  FQPSK-B  and  FQPSK-JR,  the  SOQPSK-TG,  and  the  ARTM  CPM.  Each 
of  these  methods  offers  constant,  or  nearly  constant,  envelope  characteristics  and  is  compatible 
with  nonlinear  amplifiers  with  minimal  spectral  regrowth  and  minimal  degradation  of  detection 
efficiency.  The  first  three  methods  (EQPSK-B,  EQPSK-JR,  and  SOQPSK-TG)  are  interoperable 
and  require  the  use  of  the  differential  encoder  described  in  Subsection  2. 3. 3. 1.1.  Additional 
information  on  this  differential  encoder  is  contained  in  0.  All  of  these  bandwidth-efficient 
modulation  methods  require  the  data  to  be  randomized. 

A.2.C.  Other  Notations 

The  following  notations  are  used  in  this  appendix.  Other  references  may  define  these 
terms  slightly  differently. 

a.  B99%  -  Bandwidth  containing  99%  of  the  total  power. 

b.  B-25dBm  -  Bandwidth  containing  all  components  larger  than  -25  dBm. 

c.  B-60dBc  -  Bandwidth  containing  all  components  larger  than  the  power  level  that  is  60  dB 
below  the  unmodulated  carrier  power. 

d.  dBc  -  Decibels  relative  to  the  power  level  of  the  unmodulated  carrier. 

e.  fc  -  Assigned  center  frequency. 

A.3.  Authorization  to  Use  a  Telemetry  System 

All  RE  emitting  devices  must  have  approval  to  operate  in  the  US&P  via  a  frequency 
assignment  unless  granted  an  exemption  by  the  national  authority.  The  NTIA  is  the  President’s 
designated  national  authority  and  spectrum  manager.  The  NTIA  manages  and  controls  the  use  of 
RE  spectrum  by  federal  agencies  in  US&P  territory.  Obtaining  a  frequency  assignment  involves 
the  two-step  process  of  obtaining  an  RE  spectrum  support  certification  of  major  RE  systems 
design,  followed  by  an  operational  frequency  assignment  to  the  RE  system  user.  These  steps  are 
discussed  below. 

A. 3. a.  RE  Spectrum  Support  Certification 

All  major  RE  systems  used  by  federal  agencies  must  be  submitted  to  the  NTIA,  via  the 
Interdepartment  Radio  Advisory  Committee,  for  system  review  and  spectrum  support 
certification  prior  to  committing  funds  for  acquisition/procurement.  During  the  system  review 
process,  compliance  with  applicable  RE  standards,  RE  allocation  tables,  rules,  and  regulations  is 
checked.  Eor  DoD  agencies  and  for  support  of  DoD  contracts,  this  is  accomplished  via  the 
submission  of  a  DD  Eorm  1494  to  the  MCEB.  Noncompliance  with  standards,  the  tables,  rules, 
or  regulations  can  result  in  denial  of  support,  limited  support,  or  support  on  an  unprotected  non- 
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priority  basis.  All  RF  users  must  obtain  frequency  assignments  for  any  RF  system  (even  if  not 
considered  major).  This  assignment  is  accomplished  by  submission  of  frequency  use  proposals 
through  the  appropriate  frequency  management  offices.  Frequency  assignments  may  not  be 
granted  for  major  systems  that  have  not  obtained  spectrum  support  certification. 

A.3.a(l)  Frequency  Allocation 

As  stated  before,  telemetry  systems  must  normally  operate  within  the  frequency  bands 
designated  for  their  use  in  the  Table  of  Frequency  Allocations.  With  sufficient  justification,  use 
of  other  bands  may  at  times  be  permitted,  but  the  certification  process  is  much  more  difficult, 
and  the  outcome  is  uncertain.  Even  if  certification  is  granted  on  a  noninterference  basis  to  other 
users,  the  frequency  manager  is  often  unable  to  grant  assignments  because  of  local  users  who 
will  get  interference. 

a.  Telemetry  Bands 

Air  and  space-to-ground  telemetering  is  allocated  in  the  ultra-high  frequency  (UHF) 
bands  1435  to  1535,  2200  to  2290,  and  2310  to  2390  MHz  (commonly  known  as  the  lower  L- 
band,  the  lower  S-band,  and  the  upper  S-band)  and  in  the  super-high  frequency  (SHF)  bands 
4400  to  4940  and  5091  to  5150  MHz  (commonly  known  as  lower  C-band  and  middle  C-band). 
Other  mobile  bands,  such  as  1755-1850  MHz,  can  also  be  used  at  many  test  ranges.  Since  these 
other  bands  are  not  considered  a  standard  telemetry  band  per  this  document,  potential  users  must 
coordinate,  in  advance,  with  the  individual  range(s)  and  ensure  use  of  this  band  can  be  supported 
at  the  subject  range(s)  and  that  their  technical  requirements  will  be  met. 

b.  Very  High  Frequency  Telemetry 

The  very-high  frequency  (VHF)  band,  216-265  MHz,  was  used  for  telemetry  operations 
in  the  past.  Telemetry  bands  were  moved  to  the  UHF  bands  as  of  1  January  1970  to  prevent 
interference  to  critical  government  land  mobile  and  military  tactical  communications.  Telemetry 
operation  in  this  band  is  strongly  discouraged  and  is  considered  only  on  an  exceptional  case-by¬ 
case  basis. 

A.3.a(2)  Technical  Standards 

The  MCEB  and  the  NTIA  review  proposed  telemetry  systems  for  compliance  with 
applicable  technical  standards.  Eor  the  UHE  and  SHE  telemetry  bands,  the  current  revisions  of 
the  following  standards  are  considered  applicable: 

a.  RCC  Document  IRIG  106,  Telemetry  Standards; 

b.  MIE-STD-461; 

c.  NTIA  Manual  of  Regulations  and  Procedures  for  Eederal  Radio  Erequency  Management. 

Applications  for  certification  are  also  thoroughly  checked  in  many  other  ways,  including 
necessary  and  occupied  bandwidths,  modulation  characteristics,  reasonableness  of  output  power, 
correlation  between  output  power  and  amplifier  type,  and  antenna  type  and  characteristics.  The 
associated  receiver  normally  must  be  specified  or  referenced.  The  characteristics  of  the  receiver 
are  also  verified. 

A.3.b.  Erequency  Authorization 

Spectrum  certification  of  a  telemetry  system  verifies  that  the  system  meets  the  technical 
requirements  for  successful  operation  in  the  electromagnetic  environment;  however,  a  user  is  not 
permitted  to  radiate  with  the  telemetry  system  before  requesting  and  receiving  a  specific 
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frequency  assignment.  The  assignment  process  considers  when,  where,  and  how  the  user  plans 
to  radiate.  Use  of  the  assignments  is  tightly  scheduled  by  and  among  the  individual  ranges  to 
make  the  most  efficient  use  of  the  limited  telemetry  RF  spectrum  and  to  ensure  that  one  user 
does  not  interfere  with  other  users. 

A.4.  Frequency  Usage  Guidance 

Frequency  usage  is  controlled  by  scheduling  in  the  areas  where  the  tests  will  be 
conducted.  Figure  A-1  displays  the  four  modulation  methods  addressed  in  this  section.  The 
following  recommendations  are  based  on  good  engineering  practice  for  such  usage  and  it  is 
assumed  that  the  occupied  bandwidth  fits  within  the  telemetry  band  in  all  cases. 


Normalized  Frequency  (bit  rate  =  1 ) 


PCM/FM 

ARTM  CPM 

FQPSK-JR 

SOQPSK-TG 

Figure  A- 1 .  Spectra  of  10-Mbps  PCM/FM,  ARTM  CPM,  FQPSK-JR, 

SOQPSK-TG  Signals 

A.4.a.  Minimum  Frequency  Separation 

The  minimum  required  frequency  separation  can  be  calculated  using  the  formula: 

AFQ  =  as*Rs  +  ai*R:  (A-1) 

where  AFo  =  the  minimum  required  center  frequency  separation  in  MHz; 

Rs  =  bit  rate  of  desired  signal  in  Mbps; 

Ri  =  bit  rate  of  interfering  signal  in  Mbps; 

as  is  determined  by  the  desired  signal  type  and  receiving  equipment  (Table 
A4). 


Table  A-1.  Coefficients  for  Minimum  Frequency  Separation  Calculation 

Modulation  Type 

as 

ai 

NRZ  PCM/FM 

1 .0*  for  receivers  with  resistor- inductor-capacitor  (RLC) 
final  IF  filters 

0.7  for  receivers  with  surface  acoustic  wave  (SAW)  or 
digital  IF  filters 

0.5  with  multi-symbol  detectors  (or  equivalent  devices) 

1.2 

FQPSK-B,  FQPSK-JR, 
SOQPSK-TG 

0.45 

0.65 
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ARTM  CPM 


0.35 


0.5 


*The  minimum  frequency  separation  for  typical  receivers  with  RLC  final  IF  filters  and  NRZ-L 
PCM/FM  signals  is  the  larger  of  1.5  times  the  actual  IF  -3  dB  bandwidth  and  the  value 
calculated  using  the  equation  above. 


The  minimum  spacing  needs  to  be  calculated  for  signal  1  as  the  desired  signal  and  signal 
2  as  the  interferer  and  vice  versa.  Note  that  the  values  for  at  match  the  -57  dBc  points  for  the 
four  modulation  methods  shown  in  Figure  A- 1  quite  closely.  It  is  not  surprising  that  the  required 
frequency  spacing  from  the  interferer  is  directly  related  to  the  power  spectrum  of  the  interfering 
signal.  The  values  for  as  are  a  function  of  the  effective  detection  filter  band  widths  and  the  co¬ 
channel  interference  resistance  of  the  desired  signal  modulation  method  and  detector.  The  values 
for  as  and  ai  are  slightly  conservative  for  most  cases  and  assume  the  receiver  being  used  does  not 
have  spurious  responses  that  cause  additional  interference.  This  section  was  completely 
rewritten  from  previous  editions  of  the  Telemetry  Standards  because  addition  of  new  modulation 
methods  and  new  receiving  equipment  rendered  the  old  method  obsolete.  The  values  of  as  and  ai 
were  determined  empirically  from  the  results  of  extensive  adjacent  channel  interference  testing. 
The  main  assumptions  are  as  follows. 

a.  The  NRZ  PCM/FM  signals  are  assumed  to  be  premodulation  filtered  with  a  multi-pole 
filter  with  -3  dB  point  of  0.7  times  the  bit  rate  and  the  peak  deviation  is  assumed  to  be 
approximately  0.35  times  the  bit  rate. 

b.  The  receiver  IF  filter  is  assumed  to  be  no  wider  than  1.5  times  the  bit  rate  and  provides  at 
least  6  dB  of  attenuation  of  the  interfering  signal. 

c.  The  interfering  signal  is  assumed  to  be  no  more  than  20  dB  stronger  than  the  desired 
signal. 

d.  The  receiver  is  assumed  to  be  operating  in  linear  mode;  no  significant  intermodulation 
products  or  spurious  responses  are  present. 

Examples  are  shown  below. 

5-Mbps  PCM/FM  and  0.8-Mbps  PCM/FM  using  a  receiver  with  6-MHz  IF  bandwidth  for  the 

5-Mbps  signal  (this  receiver  has  RLC  IF  filters) 

1.0*5-!- 1.2*0.8  =  5.96  MHz  1. 0*0.8 -i- 1.2*5  =  6.8  MHz  1.5*6=  9.0  MHz 

The  largest  value  is  9  MHz  and  the  frequencies  are  assigned  in  1-MHz  steps,  so  the  minimum 
spacing  is  9  MHz. 


5-Mbps  PCM/FM  and  5-Mbps  PCM/FM  using  a  receiver  with  6-MHz  IF  bandwidth  for  the 

5-Mbps  signals  (these  receivers  have  RLC  IF  filters;  see  Figure  A-2) 

1.0*5 -I- 1.2*5=  11  MHz  1.5*6=  9.0  MHz 

The  larger  value  is  1 1  MHz  and  the  frequencies  are  assigned  in  1-MHz  steps,  so  the  minimum 
spacing  is  1 1  MHz. 
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Figure  A-2.  5  Mbps  PCM/FM  Signals  with  1 1  MHz  Center  Frequency 

Separation 

5-Mbps  PCM/FM  and  5-Mbps  PCM/FM  using  a  receiver  with  6-MHz  IF  bandwidth  for  the 

5-Mbps  signal  (this  receiver  has  RLC  IF  filters  but  a  multi-symbol  detector  is  used) 

0.5*5-!- 1.2*5  =  8.5  MHz 

The  frequencies  are  assigned  in  1-MHz  steps,  so  the  minimum  spacing  is  9  MHz. 

5-Mbps  PCM/FM  and  5-Mbps  SOQPSK-TG  using  a  receiver  with  6-MHz  IF  bandwidth  for  the 

5-Mbps  signals  (this  receiver  has  RLC  IF  filters  but  a  multi-symbol  detector  is  used) 

0.5*5  -I-  0.65*5  =  5.75  MHz  0.45*5  -i- 1.2*5  =  8.25  MHz 

The  largest  value  is  8.25  MHz  and  the  frequencies  are  assigned  in  1-MHz  steps,  so  the  minimum 
spacing  is  9  MHz. 

5-Mbps  FQPSK-B  and  5-Mbps  ARTM  CPM  using  a  receiver  with  6-MHz  IF  bandwidth  for  the 

5-Mbps  signals 

0.45*5  -I-  0.5*5  =  4.75  MHz  0.35*5  -i-  0.7*5  =  5.25  MHz 

The  largest  value  is  5.25  MHz  and  the  frequencies  are  assigned  in  1-MHz  steps,  so  the  minimum 
spacing  is  6  MHz. 

10-Mbps  ARTM  CPM  and  10-Mbps  ARTM  CPM  (see  Figure  A-3) 

0.35*10-1-0.5*10  =  8.5  MHz 

The  frequencies  are  assigned  in  1-MHz  steps,  so  the  minimum  spacing  is  9  MHz. 
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Figure  A-3.  10  Mbps  ARTM  CPM  Signals  with  9  MHz  Center 

Frequency  Separation 

In  some  cases  it  may  be  desirable  to  set  aside  a  bandwidth  for  each  signal  independent  of 
other  signals.  If  one  uses  a  bandwidth  factor  of  2*ai  for  each  signal,  then  one  gets  a  separation  of 
AFo  =  ai*Rs  +  ai*Ri  and  one  gets  a  more  conservative  (wider)  separation  than  one  would  using 
AFo  =  as*Rs  +  ai*Ri  because  the  value  of  at  is  bigger  than  the  value  of  as  for  all  of  these 
modulation  methods.  One  problem  with  this  approach  is  that  it  does  not  include  receiver  or 
detector  characteristics  and  therefore  the  calculated  frequency  separations  are  often  different 
from  those  calculated  using  the  formula  in  Subsection  A.4.a. 

Examples  of  frequency  separation  are  shown  below. 

5-Mbps  PCM/FM  and  0.8-Mbps  PCM/FM  using  a  receiver  with  6-MHz  IF  bandwidth  for  the 

5-Mbps  signal  (this  receiver  has  RLC  IF  filters) 

1.2*5-1-1.2*0.8  =  6.96  MHz 

The  frequencies  are  assigned  in  1-MHz  steps,  so  the  minimum  spacing  is  7  MHz. 


5-Mbps  PCM/FM  and  5-Mbps  PCM/FM  using  a  receiver  with  6-MHz  IF  bandwidth  for  the 

5-Mbps  signals  (these  receivers  have  RLC  IF  filters) 

1.2*5-!-  1.2*5=  12  MHz 

The  frequencies  are  assigned  in  1-MHz  steps,  so  the  minimum  spacing  is  12  MHz. 


5-Mbps  PCM/FM  and  5-Mbps  PCM/FM  using  a  receiver  with  6-MHz  IF  bandwidth  for  the 

5-Mbps  signal  (this  receiver  has  RLC  IF  filters  but  a  multi-symbol  detector  is  used) 

1.2*5-!-  1.2*5=  12  MHz 

The  frequencies  are  assigned  in  1-MHz  steps,  so  the  minimum  spacing  is  12  MHz. 


5-Mbps  PCM/FM  and  5-Mbps  SOQPSK-TG  using  a  receiver  with  6-MHz  IF  bandwidth  for  the 

5-Mbps  signals  (this  receiver  has  RLC  IF  filters  but  a  multi-symbol  detector  is  used) 

1.2*5-!- 0.65*5  =  9.25  MHz 
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The  frequencies  are  assigned  in  1-MHz  steps,  so  the  minimum  spacing  is  10  MHz. 

5-Mbps  FQPSK-B  and  5-Mbps  ARTM  CPM  using  a  receiver  with  6-MHz  IF  bandwidth  for  the 

5 -Mbps  signals 

0.7*5 -I- 0.5*5  =  6  MHz 

The  frequencies  are  assigned  in  1-MHz  steps,  so  the  minimum  spacing  is  6  MHz. 


10-Mbps  ARTM  CPM  and  10-Mbps  ARTM  CPM 

0.5*10-1-0.5*10=  10  MHz 

The  frequencies  are  assigned  in  1-MHz  steps,  so  the  minimum  spacing  is  10  MHz. 

A.4.b.  Geographical  Separation 

Geographical  separation  can  be  used  to  further  reduce  the  probability  of  interference  from 
adjacent  signals. 

A.4.C.  Multicarrier  Operation 

If  two  transmitters  are  operated  simultaneously  and  sent  or  received  through  the  same 
antenna  system,  interference  due  to  intermodulation  is  likely  at  (2fi  -  f2)  and  (2f2  -  fi).  Between 
three  transmitters,  the  two-frequency  possibilities  exist,  but  intermodulation  products  may  exist 
as  well  at  (fi  -i-  f2  -  fa),  (fi  +  fa  ^  fa),  and  (fa  +  fa  ~  fi),  where  fi,  fa,  and  fa  represent  the  output 
frequencies  of  the  transmitters.  Intermodulation  products  can  arise  from  nonlinearities  in  the 
transmitter  output  circuitry  that  cause  mixing  products  between  a  transmitter  output  signal  and 
the  fundamental  signal  coming  from  nearby  transmitters.  Intermodulation  products  also  can 
arise  from  nonlinearities  in  the  antenna  systems.  The  generation  of  intermodulation  products  is 
inevitable,  but  the  effects  are  generally  of  concern  only  when  such  products  exceed  -25  dBm. 
The  general  rule  for  avoiding  third-order  intermodulation  interference  is  that  in  any  group  of 
transmitter  frequencies,  the  separation  between  any  pair  of  frequencies  should  not  be  equal  to  the 
separation  between  any  other  pair  of  frequencies.  Because  individual  signals  have  sidebands,  it 
should  be  noted  that  intermodulation  products  have  sidebands  spectrally  wider  than  the 
sidebands  of  the  individual  signals  that  caused  them. 

A.4.d.  Transmitter  Antenna  System  Emission  Testing 

Radiated  tests  will  be  made  in  lieu  of  transmitter  output  tests  only  when  the  transmitter  is 
inaccessible.  Radiated  tests  may  still  be  required  if  the  antenna  is  intended  to  be  part  of  the 
filtering  of  spurious  products  from  the  transmitter  or  is  suspected  of  generating  spurious  products 
by  itself  or  in  interaction  with  the  transmitter  and  feed  lines.  These  tests  should  be  made  with 
normal  modulation. 

A.5.  Bandwidth 

The  definitions  of  bandwidth  in  this  section  are  universally  applicable.  The  limits  shown 
here  are  applicable  for  telemetry  operations  in  the  telemetry  bands  specified  in  Chapter  2.  For 
the  purposes  of  telemetry  signal  spectral  occupancy,  the  bandwidths  used  are  B99%  and 


A-8 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  2,  July  2017 


B-25dBm.  A  power  level  of  -25  dBm  is  exactly  equivalent  to  an  attenuation  of  the  transmitter 
power  by  55  -i-  lOxlog(P)  dB  where  P  is  the  transmitter  power  expressed  in  watts.  How 
bandwidth  is  actually  measured  and  what  the  limits  are,  expressed  in  terms  of  that  measuring 
system,  are  detailed  in  the  following  paragraphs. 

A. 5. a.  Concept 

The  term  “bandwidth”  has  an  exact  meaning  in  situations  where  an  AM,  double¬ 
sideband,  or  single-sideband  signal  is  produced  with  a  band-limited  modulating  signal.  In 
systems  employing  FM  or  PM,  or  any  modulation  system  where  the  modulating  signal  is  not 
band  limited,  bandwidth  is  infinite  with  energy  extending  toward  zero  and  infinite  frequency 
falling  off  from  the  peak  value  in  some  exponential  fashion.  In  this  more  general  case, 
bandwidth  is  defined  as  the  band  of  frequencies  in  which  most  of  the  signal’s  energy  is 
contained.  The  definition  of  “most”  is  imprecise.  The  following  terms  are  applied  to  bandwidth. 

A .  5 .  a(  1 )  Authorized  B  andwidth 

For  purposes  of  this  document,  the  authorized  bandwidth  is  the  necessary  bandwidth 
required  for  transmission  and  reception  of  intelligence  and  does  not  include  allowance  for 
transmitter  drift  or  Doppler  shift. 

A.5.a(2)  Occupied  Bandwidth 

The  width  of  a  frequency  band  such  that  below  the  lower  and  above  the  upper  frequency 
limits,  the  mean  powers  emitted  are  each  equal  to  a  specified  percentage  of  the  total  mean  power 
of  a  given  emission.  Unless  otherwise  specified  by  the  ITU  for  the  appropriate  class  of  emission, 
the  specified  percentage  shall  be  0.5%.  In  this  document  occupied  bandwidth  and  B99%  are 
interchangeable. 

A.5.a(3)  Necessary  Bandwidth  for  a  Given  Class  of  Emission 

For  a  given  class  of  emission,  the  width  of  the  frequency  band  that  is  just  sufficient  to 
ensure  the  transmission  of  information  at  the  rate  and  with  the  quality  required  under  specified 
conditions.  Note:  the  term  “under  specified  conditions”  does  not  include  signal  bandwidth 
required  when  operating  with  adjacent  channel  signals  (i.e.,  potential  interferers). 

a.  The  NTIA  Manual 

This  manual  states  that  “All  reasonable  effort  shall  be  made  in  equipment  design  and 
operation  by  Government  agencies  to  maintain  the  occupied  bandwidth  of  the  emission  of  any 
authorized  transmission  as  closely  to  the  necessary  bandwidth  as  is  reasonably  practicable.” 

b.  Necessary  Bandwidth  (DD  Form  1494) 

The  necessary  bandwidth  is  part  of  the  emission  designator  on  the  DD  Form  1494.  For 
telemetry  purposes,  the  necessary  bandwidth  can  be  calculated  using  the  equations  shown  in 
Table  A-2.  Equations  for  these  and  other  modulation  methods  are  contained  in  Annex  J  of  the 
NTIA  Manual. 


Table  A-2.  B99%  for  Various  Digital  Modulation  Methods 

Description 

B99% 

NRZ  PCM/EM,  premod  filter  BW=0.7R,  Af=0.35R 

1.16R 

NRZ  PCM/EM,  no  premod  filter,  Af=0.25R 

1.18R 

NRZ  PCM/EM,  no  premod  filter,  Af=0.35R 

1.78  R 
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NRZ  PCM/FM,  no  premod  filter,  Af=0.40R 

1.93  R 

NRZ  PCM/FM,  premod  filter  BW=0.7R,  Af=0.40R 

1.57  R 

Minimum  shift  keying  (MSK),  no  filter 

1.18R 

FQPSK-B,  FQPSK-JR  or  SOQPSK-TG 

0.78  R 

ARTM  CPM 

0.56  R 

Filtered  NRZ  PCM/FM.  Bn  =  1.16*bit  rate  with  h=0.7  and  premodulation  filter  bandwidth  = 
0.7  times  bit  rate.  Example:  PCM/FM  modulation  used  to  send  5  Mbps  using  FM  with  2 
signaling  states  and  1.75  MHz  peak  deviation;  bit  rate=5*10®;  necessary  bandwidth  (Bn)  =  5.8 
MHz. 

Constant  envelope  OQPSK;  FQPSK-B,  FQPSK-JR,  or  SOQPSK-TG.  Bn  =  0.78*bit  rate. 
Example:  SOPQSK-TG  modulation  used  to  send  5  Mbps  using  4  signaling  states;  bit  rate=5*10^; 
Bn  =  3.9  MHz. 

ARTM  CPM.  Bn  =  0.56*bit  rate  with  h=4/16  and  5/16  on  alternating  symbols;  digital 
modulation  used  to  send  5  Mbps  using  FM  with  4  signaling  states  and  with  alternating 
modulation  index  each  symbol;  bit  rate=5*10®;  Bn  =  2.8  MHz. 

A.5.a(4)  Received  (or  Receiver)  Bandwidth 

The  received  bandwidth  is  usually  the  -3  dB  bandwidth  of  the  receiver  IF  section. 

A.5.b.  Bandwidth  Estimation  and  Measurement 

Various  methods  are  used  to  estimate  or  measure  the  bandwidth  of  a  signal  that  is  not 
band  limited.  The  bandwidth  measurements  are  performed  using  a  spectrum  analyzer  (or 
equivalent  device)  with  the  following  settings:  30-kHz  resolution  bandwidth,  300-Hz  video 
bandwidth,  and  no  max  hold  detector  or  averaging.  These  settings  are  different  than  those  in 
earlier  versions  of  the  Telemetry  Standards.  The  settings  were  changed  to  get  more  consistent 
results  across  a  variety  of  bit  rates,  modulation  methods,  and  spectrum  analyzers.  The  most 
common  measurement  and  estimation  methods  are  described  in  the  following  paragraphs. 

A.5.b(l)  B99% 

This  bandwidth  contains  99%  of  the  total  power.  Typically,  B99%  is  measured  using  a 
spectrum  analyzer  or  estimated  using  equations  for  the  modulation  type  and  bit  rate  used.  If  the 
two  points  that  define  the  edges  of  the  band  are  not  symmetrical  about  the  assigned  center 
frequency,  their  actual  frequencies  and  difference  should  be  noted.  The  B99%  edges  of 
randomized  NRZ  (RNRZ)  PCM/FM  signals  are  shown  in  Figure  A-4.  Table  A- 2  presents  B99% 
for  several  digital  modulation  methods  as  a  function  of  the  bit  rate  (R). 
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Figure  A-4.  RNRZ  PCM/FM  Signal 


A.5.b(2)  B-25dBm 

B-25dBm  is  the  bandwidth  containing  all  components  larger  than  -25  dBm.  A  power 
level  of  -25  dBm  is  exactly  equivalent  to  an  attenuation  of  the  transmitter  power  by  55  -i- 
lOxlog(P)  dB  where  P  is  the  transmitter  power  expressed  in  watts.  B-25dBm  limits  are  shown  in 
Figure  A-4.  B-25dBm  is  primarily  a  function  of  the  modulation  method,  transmitter  power,  and 
bit  rate.  The  transmitter  design  and  construction  techniques  also  strongly  influence  B-25dBm. 
With  a  bit  rate  of  5  Mbps  and  a  transmitter  power  of  5  watts,  the  B-25dBm  of  an  NRZ  PCM/FM 
system  with  near  optimum  parameter  settings  is  about  13.3  MHz,  while  B-25dBm  of  an 
equivalent  FQPSK-B  system  is  about  7.5  MHz,  and  B-25dBm  of  an  equivalent  ARTM  CPM 
system  is  about  5.8  MHz. 

A.5.b(3)  Scheduled  Bandwidth 

This  bandwidth  should  be  used  by  organizations  responsible  for  either  requesting  or 
scheduling  bandwidth  required  for  telemetry  signals.  These  signals  are  either  packed  tightly 
within  existing  telemetry  bands,  operating  without  adjacent  signals,  or  are  scheduled  near 
telemetry  band  edges.  Scheduled  bandwidth  should  be  calculated  for  these  three  cases  in  the 
following  manner. 

a.  If  the  telemetry  signal  will  be  operating  in  the  absence  of  adjacent  signals,  use  the  B99% 
(occupied  bandwidth)  calculations  in  Table  A-2  to  determine  scheduled  bandwidth. 

b.  If  the  telemetry  signal  will  be  operating  in  the  in  the  presence  of  adjacent  telemetry 
signals,  use  the  minimum  frequency  separation  calculations  in  Table  A-1  to  determine 
scheduled  bandwidth. 

c.  If  the  telemetry  signal  will  be  operating  near  a  telemetry  band  edge,  use  the  calculations 
in  Section  A. 12  to  determine  proper  spacing  from  the  band  edge. 


A-11 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  2,  July  2017 


A.5.C.  Other  Bandwidth  Measurement  Methods 

The  methods  discussed  above  are  the  standard  methods  for  measuring  the  bandwidth  of 
telemetry  signals.  The  following  methods  are  also  sometimes  used  to  measure  or  to  estimate  the 
bandwidth  of  telemetry  signals. 

a.  Below  Unmodulated  Carrier 

This  method  measures  the  power  spectrum  with  respect  to  the  unmodulated  carrier 
power.  To  calibrate  the  measured  spectrum  on  a  spectrum  analyzer,  the  unmodulated  carrier 
power  must  be  known.  This  power  level  is  the  0-dB  reference  (commonly  set  to  the  top  of  the 
display).  In  AM  systems,  the  carrier  power  never  changes;  in  FM  and  PM  systems,  the  carrier 
power  is  a  function  of  the  modulating  signal.  Therefore,  a  method  to  estimate  the  unmodulated 
carrier  power  is  required  if  the  modulation  cannot  be  turned  off.  For  most  practical  angle 
modulated  systems,  the  total  carrier  power  at  the  spectrum  analyzer  input  can  be  found  by  setting 
the  spectrum  analyzer’s  resolution  and  video  bandwidths  to  their  widest  settings,  setting  the 
analyzer  output  to  max  hold,  and  allowing  the  analyzer  to  make  several  sweeps  (see  Figure  A-3). 
The  maximum  value  of  this  trace  will  be  a  good  approximation  of  the  unmodulated  carrier  level. 
Figure  A-5  shows  the  spectrum  of  a  5 -Mbps  RNRZ  PCM/FM  signal  measured  using  the  standard 
spectrum  analyzer  settings  discussed  previously  and  the  spectrum  measured  using  3-MHz 
resolution,  video  bandwidths,  and  max  hold. 


FREQUENCY  (MHz) 

Figure  A-5.  Spectrum  Analyzer  Calibration  of  0-dBc  Level 

The  peak  of  the  spectrum  measured  with  the  latter  conditions  is  very  close  to  0-dBc  and 
can  be  used  to  estimate  the  unmodulated  carrier  power  (0-dBc)  in  the  presence  of  FM  or  PM.  In 
practice,  the  0-dBc  calibration  would  be  performed  first,  and  the  display  settings  would  then  be 
adjusted  to  use  the  peak  of  the  curve  as  the  reference  level  (0-dBc  level)  to  calibrate  the  spectrum 
measured  using  the  standard  spectrum  analyzer  settings.  With  the  spectrum  analyzer  set  for  a 
specific  resolution  bandwidth,  video  bandwidth,  and  detector  type,  the  bandwidth  is  taken  as  the 
distance  between  the  two  points  outside  of  which  the  spectrum  is  thereafter  some  number  (say, 

60  dB)  below  the  unmodulated  carrier  power  determined  above.  B-60dBc  for  the  5-Mbps  signal 
shown  in  Figure  A-5  is  approximately  13  MHz. 
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B-60dBc  of  an  RNRZ  PCM/FM  signal  with  a  peak  deviation  of  0.35R,  a  four-pole 
premodulation  filter  with  -3  dB  corner  at  0.7R,  and  a  bit  rate  greater  than  or  equal  to  1  Mbps  can 
be  approximated  by  the  following  equation: 

B  -60dBc  =[2.7 8-0.3 *\ogio{R)]*  R 

(A-2) 

where  B  is  in  MHz; 

R  is  in  Mbps. 

Thus  B-60dBc  of  a  5-Mbps  RNRZ  signal  under  these  conditions  would  be  approximately 
12.85  MHz.  B-60dBc  will  be  greater  if  peak  deviation  is  increased  or  the  number  of  filter  poles 
is  decreased. 

b.  Below  Peak 

This  method  is  not  recommended  for  measuring  the  bandwidth  of  telemetry  signals.  The 
modulated  peak  method,  the  least  accurate  measurement  method,  measures  between  points 
where  the  spectrum  is  thereafter  XX  dB  below  the  level  of  the  highest  point  on  the  modulated 
spectrum.  Figure  A-6  shows  the  RF  spectrum  of  a  400-kbps  bi-phase  (Bi(j))-level  PCM/PM 
signal  with  a  peak  deviation  of  75°  and  a  pre-modulation  filter  bandwidth  of  800  kHz. 


The  largest  peak  has  a  power  level  of  -7  dBc.  In  comparison,  the  largest  peak  in  Figure 
A-5  had  a  power  level  of  -22  dBc.  This  15-dB  difference  would  skew  a  bandwidth  comparison 
that  used  the  peak  level  in  the  measured  spectrum  as  a  common  reference  point.  In  the  absence 
of  an  unmodulated  carrier  to  use  for  calibration,  the  below-peak  measurement  is  often 
(erroneously)  used  and  described  as  a  below-unmodulated-carrier  measurement.  Using  max  hold 
exacerbates  this  effect  still  further.  In  all  instances  the  bandwidth  is  overstated,  but  the  amount 
varies. 


c.  Carson ’s  Rule 

Carson’s  Rule  is  a  method  to  estimate  the  bandwidth  of  an  FM  subcarrier  system. 
Carson’s  Rule  states  the  following: 

^  =  2(A/  -I-  /  max) 
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where  B  is  the  bandwidth; 

Af  is  the  peak  deviation  of  the  carrier  frequency; 
fmax  is  the  highest  frequency  in  the  modulating  signal. 

Figure  A-7  shows  the  spectrum  that  results  when  a  12-channel  constant  bandwidth 
multiplex  with  6-dB/octave  pre-emphasis  frequency  modulates  an  FM  transmitter.  B99%  and 
the  bandwidth  calculated  using  Carson’s  Rule  are  also  shown.  Carson’s  Rule  will  estimate  a 
value  greater  than  B99%  if  little  of  the  carrier  deviation  is  due  to  high-frequency  energy  in  the 
modulating  signal. 


A.5.d.  Spectral  Equations 

The  following  equations  can  be  used  to  calculate  the  RF  spectra  for  several  digital 
modulation  methods  with  unfiltered  waveforms. These  equations  can  be  modified  to 
include  the  effects  of  filtering. 

RNRZ  PCM/FM  (valid  when  D^^integer,  D  =  0.5  gives  MSK  spectrum) 


S(f)- 


4B. 


SA 


R 


D 


7^(D--X‘) 


(cos  ttD  -  cos  7lX  )~’ 

1-2  cos  ttDcosttX  +  cos^  ^4) 


cos  7tD<Q 


(A-4) 
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RNRZ  PSK 
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RNRZ  QPSK  and  OQPSK 
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Random  Bitj)  PCM/FM 
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Random  Bitj)  PCM/PM 


S(f)= 


Bsa  sin^  (  /^  ) 


sm 


ttX 


V 


TT 


R 


"ttX^ 

V  4  ) 


+  cos( 


(A-8) 


where  S(f)  =  power  spectrum  (dBc)  at  frequency  f 

Bsa  =  spectrum  analyzer  resolution  bandwidth* 

R  =  bit  rate 

D  =  2Af/R 

X  =  2(f-fc)/R 

Af  =  peak  deviation 

P  =  peak  phase  deviation  in  radians 

fc  =  carrier  frequency 

5  =  Dirac  delta  function 

N  =  0,±l,±2,  ... 

Q  =  quantity  related  to  narrow  band  spectral  peaking  when  D«l,  2,  3, ... 
Q  «  0.99  for  Bsa  =  0.003  R,  Q  «  0.9  for  Bsa  =  0.03  R 
*The  spectrum  analyzer  resolution  bandwidth  term  was  added  to  the  original  equations. 
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A.5.e.  Receiver  Bandwidth 

Receiver  predetection  bandwidth  is  typically  defined  as  the  points  where  the  response  to 
the  carrier  before  demodulation  is  -3  dB  from  the  center  frequency  response.  The  carrier 
bandwidth  response  of  the  receiver  is,  or  is  intended  to  be,  symmetrical  about  the  carrier  in  most 
instances.  Figure  A- 8  shows  the  response  of  a  typical  older- generation  telemetry  receiver  with 
RLC  IF  filters  and  a  1-MHz  IF  bandwidth  selected.  Outside  the  stated  bandwidth,  the  response 
usually  falls  fairly  rapidly,  often  20  dB  or  more  below  the  passband  response  at  1.5  to  2  times  the 
passband  response. 


I  - 1 - 1 - 1 - T - — - -T - 1 - 1 - 1 

18  19  20  21  22 

FREQUENCY  (MHz) 


Figure  A-8.  Typical  Receiver  RLC  IF  Filter  Response  (-3  dB  Bandwidth 

=  1  MHz) 

Figure  A-9  shows  an  overlay  of  an  RLC  IF  filter  and  a  SAW  filter.  Note  that  the  SAW 
filter  rolls  off  much  more  rapidly  than  the  RLC  filter.  The  rapid  falloff  outside  the  passband 
helps  reduce  interference  from  nearby  channels  and  has  minimal  effect  on  data. 


60  65  70  75  80 

Frequency  (MHz) 


_ _ RLC  - SAW 

Figure  A-9.  RLC  and  SAW  IF  Filters 
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A.5.f.  Receiver  Noise  Bandwidth 

For  the  purpose  of  calculating  noise  in  the  receiver,  the  bandwidth  must  be  integrated 
over  the  actual  shape  of  the  IF,  which,  in  general,  is  not  a  square-sided  function.  Typically,  the 
value  used  for  noise  power  calculations  is  the  -3  dB  bandwidth  of  the  receiver. 

A.5.g.  Symmetry 

Many  modulation  methods  produce  a  spectrum  that  is  asymmetrical  with  respect  to  the 
carrier  frequency.  Exceptions  include  FM/FM  systems,  RNRZ  PCM/FM  systems,  and 
randomized  FQPSK,  SOQPSK-TG,  and  ARTM  CPM  systems.  The  most  extreme  case  of 
asymmetry  is  due  to  single-sideband  transmission,  which  places  the  carrier  frequency  at  one  edge 
of  the  occupied  spectrum.  If  the  spectrum  is  not  symmetrical  about  the  band  center,  the 
bandwidth  and  the  extent  of  asymmetry  must  be  noted  for  frequency  management  purposes. 

A.5.h.  FM  Transmitters  (alternating  current-coupled) 

Alternating  current-coupled  FM  transmitters  should  not  be  used  to  transmit  NRZ  signals 
unless  the  signals  to  be  transmitted  are  randomized.  This  is  because  changes  in  the  ratio  of  Is  to 
Os  will  increase  the  occupied  bandwidth  and  may  degrade  the  BER.  When  alternating  current- 
coupled  transmitters  are  used  with  RNRZ  signals,  it  is  recommended  that  the  lower  -3  dB 
frequency  response  of  the  transmitter  be  no  greater  than  the  bit  rate  divided  by  4000.  Eor 
example,  if  a  randomized  1-Mbps  NRZ  signal  is  being  transmitted,  the  lower  -3  dB  frequency 
response  of  the  transmitter  should  be  no  larger  than  250  Hz. 

A.6.  Spectral  Occupancy  Limits 

Telemetry  applications  covered  by  this  standard  shall  use  B99%  to  define  occupied 
bandwidth  and  B-25dBm  as  the  primary  measure  of  spectral  efficiency.  The  spectra  are  assumed 
symmetrical  about  the  center  frequency  unless  otherwise  specified.  The  primary  reason  for 
controlling  the  spectral  occupancy  is  to  control  adjacent  channel  interference,  thereby  allowing 
more  users  to  be  packed  into  a  given  amount  of  frequency  spectrum.  The  adjacent  channel 
interference  is  determined  by  the  spectra  of  the  signals  and  the  filter  characteristics  of  the 
receiver. 

A. 6. a.  Spectral  Mask 

One  common  method  of  describing  the  spectral  occupancy  limits  is  a  spectral  mask.  The 
aeronautical  telemetry  spectral  mask  is  described  below.  Note  that  the  mask  in  this  standard  is 
different  than  the  masks  contained  in  the  earlier  versions  of  the  Telemetry  Standards.  All 
spectral  components  larger  than  -[55  -i-  lOxlog(P)]  dBc  (i.e.,  larger  than  -25  dBm)  at  the 
transmitter  output  must  be  within  the  spectral  mask  calculated  using  the  following  equation: 

M  (/)=/:  -f  90  log  - 1 00  log|/  -  /c|;  \f  -fc\>~  (A-9) 

m 

where  M(/)  =  power  (dBc)  at  frequency  f  (MHz) 

K  =  -20  for  analog  signals 
K  =  -28  for  binary  signals 
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K  =  -61  for  FQPSK-B,  FQPSK-JR,  SOQPSK-TG 

K  =  -73  for  ARTM  CPM 

fc  =  transmitter  center  frequency  (MHz) 

R  =  bit  rate  (Mbps)  for  digital  signals  or  (Af +fmax)(.MHz)  for  analog  FM 
signals 

M  =  number  of  states  in  modulating  signal  (m  =  2  for  binary  signals,  m  = 

4  for  quaternary  signals  and  analog  signals) 

^  f  =  peak  deviation 

fmax  =  maximum  modulation  frequency 

These  bandwidths  are  measured  using  a  spectrum  analyzer  with  settings  of  30-kHz 
resolution  bandwidth,  300-Hz  video  bandwidth,  and  no  max  hold  detector  or  averaging.  Note 
that  these  settings  are  different  than  those  listed  in  previous  editions  of  the  Telemetry  Standards. 
The  changes  were  made  to  get  more  consistent  results  with  various  bit  rates  and  spectrum 
analyzers.  The  spectra  measured  with  these  settings  give  slightly  larger  power  levels  than  with 
the  previous  settings;  this  is  why  the  value  of  K  was  changed  from  -63  to  -61  for  FQPSK  and 
SOQPSK  signals.  The  power  levels  near  center  frequency  should  be  approximately  J-lOlog(R) 
dBc  where  J=  -10  for  ARTM  CPM,  -12  for  FQPSK  and  SOQPSK-TG,  and  -15.5  for  PCM/FM 
signals.  For  a  bit  rate  of  5  Mbps,  the  level  is  approximately  -17  dBc  for  ARTM  CPM,  -19  dBc 
for  FQPSK,  and  -22.5  dBc  for  PCM/FM.  If  the  power  levels  near  center  frequency  are  not 
within  3  dB  of  these  values,  then  a  measurement  problem  exists  and  the  carrier  power  level  (0 
dBc)  and  spectrum  analyzer  settings  should  be  verified. 

B-25dBm  is  not  required  to  be  narrower  than  1  MHz.  The  first  term  K  in  equation  A-9 
accounts  for  bandwidth  differences  between  modulation  methods.  Equation  A-9  can  be  rewritten 
as  M(f)  =  K  -  lOlogR  -  1001ogl(f-fc)/RI.  When  equation  A-9  is  written  this  way,  the  lOlogR 
term  accounts  for  the  increased  spectral  spreading  and  decreased  power  per  unit  bandwidth  as  the 
modulation  rate  increases.  The  last  term  forces  the  spectral  mask  to  roll  off  at  30  dB/octave 
(100  dB/decade).  Any  error  detection  or  error  correction  bits,  which  are  added  to  the  data 
stream,  are  counted  as  bits  for  the  purposes  of  this  spectral  mask.  The  spectral  masks  are  based 
on  the  power  spectra  of  random  real-world  transmitter  signals.  For  instance,  the  binary  signal 
spectral  mask  is  based  on  the  power  spectrum  of  a  binary  NRZ  PCM/FM  signal  with  peak 
deviation  equal  to  0.35  times  the  bit  rate  and  a  multipole  premodulation  filter  with  a  -3  dB 
frequency  equal  to  0.7  times  the  bit  rate  (see  Figure  A-4).  This  peak  deviation  minimizes  the 
BER  with  an  optimum  receiver  bandwidth  while  also  providing  a  compact  RE  spectrum.  The 
premodulation  filter  attenuates  the  RE  sidebands  while  only  degrading  the  BER  by  the  equivalent 
of  a  few  tenths  of  a  dB  of  RE  power.  Eurther  decreasing  of  the  premodulation  filter  bandwidth 
will  only  result  in  a  slightly  narrower  RE  spectrum,  but  the  BER  will  increase  dramatically. 
Increasing  the  premodulation  filter  bandwidth  will  result  in  a  wider  RE  spectrum,  and  the  BER 
will  only  be  decreased  slightly.  The  recommended  premodulation  filter  for  NRZ  PCM/EM 
signals  is  a  multipole  linear  phase  filter  with  a  -3  dB  frequency  equal  to  0.7  times  the  bit  rate. 
The  unfiltered  NRZ  PCM/EM  signal  rolls  off  at  12  dB/octave  so  at  least  a  three-pole  filter  (filters 
with  four  or  more  poles  are  recommended)  is  required  to  achieve  the  30  dB/octave  slope  of  the 
spectral  mask.  The  spectral  mask  includes  the  effects  of  reasonable  component  variations  (unit- 
to-unit  and  temperature). 
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A.6.b.  Spectral  Mask  Examples 

Figure  A- 10  and  Figure  A- 11  show  the  binary  spectral  mask  of  equation  A-9  and  the  RF 
spectra  of  5-Mbps  RNRZ  PCM/FM  signals.  The  RF  spectra  were  measured  using  a  spectrum 
analyzer  with  30-kHz  resolution  bandwidth,  300-Hz  video  bandwidth,  and  no  max  hold  detector. 
The  span  of  the  frequency  axis  is  20  MHz.  The  transmitter  power  was  5  watts,  and  the  peak 
deviation  was  1750  kHz.  The  modulation  signal  for  Figure  A- 10  was  filtered  with  a  4-pole 
linear-phase  filter  with  -3  dB  frequency  of  3500  kHz.  All  spectral  components  in  Figure  A- 10 
were  contained  within  the  spectral  mask.  The  minimum  value  of  the  spectral  mask  was  -62  dBc 
(equivalent  to  -25  dBm).  The  peak  modulated  signal  power  levels  were  about  22.5  dB  below  the 
unmodulated  carrier  level  (-22.5  dBc).  Figure  A- 1 1  shows  the  same  signal  with  no 
premodulation  filtering.  The  signal  was  not  contained  within  the  spectral  mask  when  a 
premodulation  filter  was  not  used. 


Frequency  (MHz) 

Figure  A- 10.  Filtered  5-Mbps  RNRZ  PCM/FM  Signal  and  Spectral  Mask 


1440.5  1450.5  1460.5 

Frequency  (MHz) 

Figure  A- 1 1 .  Unfiltered  5-Mbps  RNRZ  PCM/FM  Signal  and  Spectral 

Mask 

Figure  A- 12  shows  the  FQPSK/SOQPSK  mask  of  equation  A-9  and  the  RF  spectrum  of  a 
5-Mbps  SOQPSK-TG  signal.  The  transmitter  power  was  assumed  to  be  5  watts  in  this  example. 
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The  peak  value  of  the  SOQPSK-TG  signal  was  about  -19  dBc.  Figure  A- 13  shows  a  typical  5- 
Mbps  ARTM  CPM  signal  and  its  spectral  mask.  The  peak  value  of  the  ARTM  CPM  signal  was 
about  -17  dBc. 


Figure  A-12.  Typical  5-Mbps  SOQPSK  TG  Signal  and  Spectral  Mask 


1440.5  1450,5  1460.5 

Frequency  (MHz) 

Figure  A-13.  Typical  5-Mbps  ARTM  CPM  Signal  and  Spectral  Mask 

A.7.  Technical  Characteristics  of  Digital  Modulation  Methods 


Table  A-3  provides  a  summary  of  some  of  the  technical  characteristics  of  the  modulation 
methods  discussed  in  this  summary. 


Table  A-3.  Characteristics  of  Various  Modulation  Methods 

Characteristic 

PCM/EM  with 
single  symbol 
detection 

PCM/EM  with 

multi-symbol 

detection 

EQPSK-B, 

EQPSK-JR, 

SOQPSK-TG 

ARTM  CPM 

Occupied  Bandwidth 

1.16  bit  rate 

1.16  bit  rate 

0.78  bit  rate 

0.56  bit  rate 

Sensitivity 

(Eb/No  for  BEP=le-5) 

11.8-15-1-  dB 

9.5  dB 

11.8-12.2  dB 

12.5  dB 
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Synchronization  time 

100  to  10,000 
bits 

250  bits 

5,000  to  30,000 
bits 

30,000  to 
150,000  bits 

Synchronization 
threshold  level  (Eb/No) 

3  to  4  dB 

2dB 

4.5  to  5  dB 

8.5  dB 

Phase  noise 
susceptibility* 

2 

1 

3 

4 

Co-channel 

interference 

susceptibility* 

2 

1 

3 

4 

*  l=Best,  2=Second  Best,  3=Third  Best,  ^ 

=Worst 

A.8.  FQPSK-B  and  FQPSK-JR  Characteristics 

Modulations  of  FQPSK-B  and  FQPSK-JR  are  a  variation  of  OQPSK,  which  is  described 
in  most  communications  textbooks.  A  generic  OQPSK  (or  quadrature  or  I  &  Q)  modulator  is 
shown  in  Figure  A- 14.  In  general,  the  odd  bits  are  applied  to  one  channel  (say  Q),  and  the  even 
bits  are  applied  to  the  I  channel. 


1(0 

Cos(a)ct) 

1 

Cos(a)ct  +6(0) 

Q(t) 

J  * 

, 

Sin((Oct) 

Figure  A- 14.  OQPSK  Modulator 


If  the  values  of  I  and  Q  are  +1,  we  get  the  diagram  shown  in  Figure  A- 15.  For  example, 
if  1=1  and  Q=1  then  the  phase  angle  is  45  degrees  {(I,Q)  =  (1,1)}.  A  constant  envelope 
modulation  method,  such  as  MSK,  would  follow  the  circle  indicated  by  the  small  dots  in  Figure 
A-15  to  go  between  the  large  dots.  In  general,  band- limited  QPSK  and  OQPSK  signals  are  not 
constant  envelope  and  would  not  follow  the  path  indicated  by  the  small  dots  but  rather  would 
have  a  significant  amount  of  amplitude  variation;  however,  FQPSK-B  and  FQPSK-JR  are  nearly 
constant  envelope  and  essentially  follow  the  path  indicated  by  the  small  dots  in  Figure  A-15. 
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Figure  A- 15.  I  and  Q  Constellation 


The  typical  implementation  of  FQPSK-B  or  FQPSK-JR  involves  the  application  of  data 
and  a  bit  rate  clock  to  the  baseband  processor  of  the  quadrature  modulator.  The  data  are 
differentially  encoded  and  converted  to  I  and  Q  signals  as  described  in  Chapter  2.  The  I  and  Q 
channels  are  then  cross-correlated,  and  specialized  wavelets  are  assembled  that  minimize  the 
instantaneous  variation  of  (I^(t)  -i-  Q^(t)).  The  FQPSK-B  baseband  wavelets  are  illustrated  in 
Figure  A- 16. 


Figure  A- 16.  FQPSK  Wavelet  Eye  Diagram 


The  appropriate  wavelet  is  assembled  based  on  the  current  and  immediate  past  states  of  I 
and  Q,  where  Q  is  delayed  by  one-half  symbol  (one  bit)  with  respect  to  I  as  shown  in  Figure 
A-17. 


A-22 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  2,  July  2017 


Figure  A- 17.  FQPSK-B  I  &  Q  Eye  Diagrams  (at  Input  to  IQ  Modulator) 

A  eommon  method  at  looking  at  I-Q  modulation  signals  is  the  use  of  a  veetor  diagram. 
One  method  of  generating  a  vector  diagram  is  to  use  an  oscilloscope  that  has  an  XY  mode.  The 
vector  diagram  is  generated  by  applying  the  I  signal  to  the  X  input  and  the  Q  signal  to  the  Y 
input.  A  sample  vector  diagram  of  FQPSK-B  at  the  input  terminals  of  an  I-Q  modulator  is 
illustrated  in  Figure  A- 18.  Note  that  the  vector  diagram  values  are  always  within  a  few  percent 
of  being  on  a  circle.  Any  amplitude  variations  may  cause  spectral  spreading  at  the  output  of  a 
nonlinear  amplifier. 


Figure  A-18.  FQPSK-B  Vector  Diagram 

Figure  A- 19  illustrates  a  nearly  ideal  FQPSK-JR  spectrum  (blue  trace)  and  an  FQPSK-JR 
spectrum  with  moderately  large  modulator  errors  (red  trace).  These  spectra  were  measured  at  the 
output  of  a  fully  saturated  RF  nonlinear  amplifier  with  a  random  pattern  of  Is  and  Os  applied  to 
the  input.  The  bit  rate  for  Figure  A- 19  was  5  Mbps.  The  peak  of  the  spectrum  was 
approximately  -19  dBc.  B99%  of  FQPSK-B  is  typically  about  0.78  times  the  bit  rate.  Note  that 
with  a  properly  randomized  data  sequence  and  proper  transmitter  design,  FQPSK-B  does  not 
have  significant  sidebands  (blue  trace). 
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Figure  A- 19.  5  Mbps  FQPSK-JR  Spectrum  with  Random  Input  Data  and 
Small  (Blue)  and  Large  (Red)  Modulator  Errors 

Figure  A-20  illustrates  an  FQPSK-B  transmitter  output  with  all  Os  as  the  input  signal. 
With  an  all  Os  input,  the  differential  encoder,  cross-correlator,  and  wavelet  selector  provide  unity 
amplitude  sine  and  cosine  waves  with  a  frequency  equal  to  0.25  times  the  bit  rate  to  the  I  and  Q 
modulator  inputs.  The  resulting  signal  (from  an  ideal  modulator)  would  be  a  single  frequency 
component  offset  from  the  carrier  frequency  by  exactly  -1-0.25  times  the  bit  rate.  The  amplitude 
of  this  component  would  be  equal  to  0  dBc.  If  modulator  errors  exist  (they  always  will), 
additional  frequencies  will  appear  in  the  spectrum  as  shown  in  Figure  A-20.  The  spectral  line  at 
a  normalized  frequency  of  0  (carrier  frequency)  is  referred  to  as  the  remnant  carrier.  This 
component  is  largely  caused  by  direct  current  imbalances  in  the  I  and  Q  signals.  The  remnant 
carrier  power  in  Figure  A-20  is  approximately  -31  dBc.  Well-designed  FQPSK-B  transmitters 
will  have  a  remnant  carrier  level  less  than  -30  dBc.  The  spectral  component  offset,  0.25  times 
the  bit  rate  below  the  carrier  frequency,  is  the  other  sideband.  This  component  is  largely  caused 
by  unequal  amplitudes  in  I  and  Q  and  by  a  lack  of  quadrature  between  I  and  Q.  The  power  in 
this  component  should  be  limited  to  -30  dBc  or  less  for  good  system  performance. 


Figure  A-20.  FQPSK-B  Spectrum  with  All  O’s  Input  and  Large  Modulator 

Errors 

Eigure  A-21  shows  the  measured  BEP  versus  signal  energy  per  bit/noise  power  per  Hz 
(Eb/No)  of  two  EQPSK-JR  modulator/demodulator  combinations  including  nonlinear 
amplification  and  differential  encoding/decoding  in  an  additive  white  Gaussian  noise  (AWGN) 
environment  with  no  fading.  Other  combinations  of  equipment  may  have  different  performance. 
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Phase  noise  levels  higher  than  those  recommended  in  Chapter  2  can  significantly  degrade  the 
BEP  performance.  Computer  simulations  have  shown  that  a  BEP  of  10“^  may  be  achievable 
with  an  Eb/No  of  slightly  greater  than  1 1  dB  (with  differential  encoding/decoding).  The  purpose 
of  the  differential  encoder/decoder  is  to  resolve  the  phase  detection  ambiguities  that  are  inherent 
in  QPSK,  OQPSK,  and  EQPSK  modulation  methods.  The  differential  encoder/decoder  used  in 
this  standard  will  cause  one  isolated  symbol  error  to  appear  as  two  bits  in  error  at  the 
demodulator  output;  however,  many  aeronautical  telemetry  channels  are  dominated  by  fairly 
long  burst  error  events,  and  the  effect  of  the  differential  encoder/decoder  will  often  be  masked  by 
the  error  events. 


Eigure  A-21 .  EQPSK- JR  BEP  vs.  Eb/NO 


A.9.  SOQPSK-TG  Characteristics 

The  SOQPSK  is  a  family  of  constant  envelope  CPM  waveforms  defined  by  Hill.^^  The 
details  of  SOQPSK-TG  are  described  in  Subsection  2. 3. 3. 2.  The  SOQPSK-TG  signal  amplitude 
is  constant  and  the  phase  trajectory  is  determined  by  the  coefficients  in  Table  2-4.  Therefore, 
SOQPSK-TG  can  be  implemented  using  a  precision  phase  or  frequency  modulator  with  proper 
control  of  the  phase  trajectory.  Eigure  A-22  illustrates  the  measured  phase  trajectory  of  an 
SOQPSK-TG  signal.  The  vertical  lines  correspond  approximately  to  the  “bit”  decision  times. 


0  4  8  12  16 

Bit  number 

Eigure  A-22.  Measured  SOQPSK-TG  Phase  Trajectory 


Hill,  “An  Enhanced,  Constant  Envelope,  Interoperable  Shaped  Offset  QPSK.” 
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The  power  spectrum  of  a  random  5-Mbps  SOQPSK-TG  signal  is  shown  in  Figure  A-23. 
B-60dBc  of  this  5-Mbps  signal  was  about  7.34  MHz.  Note  that  the  maximum  power  level  is 
about  -19  dBc. 


Figure  A-23.  SOQPSK-TG  Power  Spectrum  (5  Mbps) 

Figure  A-24  shows  the  measured  BEP  versus  signal  energy  per  bit/noise  power  per  Hz 
(Eb/No)  of  two  SOQPSK-TG  modulator/demodulator  combinations  including  nonlinear 
amplification  and  differential  encoding/decoding  in  an  AWGN  environment  with  no  fading. 
Other  combinations  of  equipment  may  have  different  performance.  Phase  noise  levels  higher 
than  those  recommended  in  Chapter  2  can  significantly  degrade  the  BEP  performance. 


Eigure  A-24.  BEP  vs.  Eb/NO  Performance  of  5  Mbps  SOQPSK-TG 


A.IO.  Advanced  Range  Telemetry  Continuous  Phase  Modulation  Characteristics 

The  ARTM  CPM  is  a  quaternary  signaling  scheme  in  which  the  instantaneous  frequency 
of  the  modulated  signal  is  a  function  of  the  source  data  stream.  The  frequency  pulses  are  shaped 
for  spectral  containment  purposes.  As  defined  for  this  standard,  the  modulation  index  alternates 
at  the  symbol  rate  between  h=4/16  and  h=5/16.  The  purpose  of  alternating  between  two 
modulation  indices  is  to  maximize  the  minimum  distance  between  data  symbols,  which  results  in 
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minimizing  the  BEP.  These  particular  modulation  indices  were  selected  as  a  good  tradeoff 
between  spectral  efficiency  and  data-detection  ability.  Figure  A-25  shows  the  power  spectrum  of 
a  5-Mbps  ARTM  CPM  signal  and  Figure  A-26  shows  the  measured  BEP  versus  Eb/No.  The 
maximum  power  level  was  about  -19  dBc.  B-60dBc  of  this  5-Mbps  signal  was  about  5.54  MHz. 
Note  that  the  power  spectrum  of  ARTM  CPM  is  about  25%  narrower  than  that  of  SOQPSK-TG 
but  the  BEP  performance  is  worse.  The  ARTM  CPM  is  also  more  susceptible  to  phase  noise 
than  SOQPSK-TG. 


Figure  A-25.  Power  Spectrum  of  5  Mbps  ARTM  CPM 


Figure  A-26.  BEP  vs.  Eb/NO  Performance  of  5  Mbps  ARTM  CPM 

A.ll.  PCM/FM 

The  most  popular  telemetry  modulation  since  1970  is  PCM/  EM,  also  known  as  CPFSK. 
The  RE  signal  is  typically  generated  by  filtering  the  baseband  NRZ-E  signal  and  then  frequency 
modulating  a  VCO.  The  optimum  peak  deviation  is  0.35  times  the  bit  rate  (h=0.7)  and  a  good 
choice  for  a  premodulation  filter  is  a  multi-pole  linear  phase  filter  with  bandwidth  equal  to  0.7 
times  the  bit  rate.  Figure  A- 27  shows  the  power  spectrum  of  a  pseudo-random  5-Mbps  PCM/FM 
signal  with  peak  deviation  of  1.75  MHz  and  a  3.5-MHz  linear  phase  low-pass  filter.  Note  that 
the  spectrum  is  nearly  flat  from  a  frequency  equal  to  -0.5  times  the  bit  rate  to  a  frequency  equal 
to  -1-0.5  times  the  bit  rate.  The  power  level  near  the  center  frequency  is  about  -22.5  dBc  for  a  bit 
rate  of  5  Mbps  and  the  standard  spectrum  analyzer  settings. 
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Figure  A-27.  Power  Spectrum  of  5  Mbps  PCM/FM  Signal 


Figure  A-28  shows  the  BEP  versus  Eb/No  performance  of  5 -Mbps  PCM/EM  with  a  multi¬ 
symbol  bit  detector  and  with  three  different  receivers/detectors.  Note  that  an  Eb/No  of  about  9.5 
dB  is  required  to  achieve  a  BEP  of  about  10“^  with  the  multi-symbol  detector^®’  while  an  Eb/No 
of  about  12  to  14  dB  is  typically  required  to  achieve  a  BEP  of  about  10”^  with  typical  PM 
demodulators  and  single-symbol  detectors.  The  PCM/PM  modulation  method  is  fairly 
insensitive  to  phase  noise. 


Eb/No  (dB) 


R1  —  Multi-symbol^^  R2  ^  R3 

Pigure  A-28.  BEP  vs.  Eb/NO  Performance  of  5-Mbps  PCM/PM  with 
Multi-Symbol  Bit  Detector  and  Three  Single-Symbol  Receivers/Detectors 

A.12.  Valid  Center  Frequencies  Near  Telemetry  Band  Edges 

The  telemetry  bands  and  associated  frequency  ranges  identified  in  Table  2-1  identify  the 
frequency  limits  for  each  band.  Telemetry  transmitters  cannot  be  centered  at  the  band  edges  due 
to  obvious  out-of-band  emissions  (OOBE).  Bit  rate  to  the  transmitter  and  modulation  scheme 
drive  the  amount  of  separation  required  between  the  center  frequency  and  the  band  edge.  To 


Osborne,  W.  P.  and  M.  B.  Luntz.  “Coherent  and  Noncoherent  Detection  of  CPFSK,”  IEEE  Transactions  on 
Communications,  August  1974. 

Mark  Geoghegan.  “Improving  the  Detection  Efficiency  of  Conventional  PCM/EM  Telemetry  by  using  a  Multi- 
Symbol  Demodulator”,  Proceedings  of  the  2000  International  Telemetry  Conference,  Volume  XXXVI,  675-682, 
San  Diego  CA,  October  2000. 
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determine  the  amount  of  back-off  required,  the  distance  from  the  center  of  the  spectral  masks  for 
each  modulation  scheme  (see  Subsection  2.3.6)  to  the  intersection  of  the  mask  and  the  absolute 
limit  of  -25  dBm  must  be  calculated.  To  illustrate  this,  see  Figure  A-29.  Using  these 
calculations  will  assure  that  outside  the  specified  telemetry  bands  no  part  of  the  modulated 
spectrum  is  over  the  absolute  limit  of  -25  dBm. 


The  mask  is  calculated  for  all  the  modulation  schemes  at  a  bit  rate  of  5  Mbps  with 
transmitter  output  power  assumed  to  be  10  W.  This  transmitter  operating  with  PCM/FM  as  its 
modulation  scheme  requires  a  back-off  from  band  edge  of  9.98  MHz;  since  channelization  in 
these  bands  is  limited  to  0.5-MHz  steps,  this  value  is  rounded  up  to  10  MHz.  This  same 
transmitter  operating  with  SOQPSK/FQPSK  will  require  4.67  MHz,  rounded  up  to  5  MHz,  of 
back-off  from  band  edge.  Likewise,  for  ARTM-CPM  the  back-off  is  3.54  MHz  or  4  Mbps  when 
rounded  up.  To  further  this  example,  if  this  was  an  L-band  transmitter,  viable  carrier  frequencies 
would  be  as  specified  in  Table  A-4. 


Table  A-4.  L-Band  Frequency  Range  (10  W,  5  Mbps) 

Modulation  Type 

Viable  L-Band  Frequency  Range 

PCM/FM 

1445-1515  MHz 

SOQPSK/FQPSK 

1440-1520  MHz 

ARTM  CPM 

1439-1521  MHz 

For  a  given  modulation  scheme  and  transmitter  output  power,  as  the  bit  rate  increases,  the 
amount  of  back-off  from  the  band  edge  also  increases.  Figure  A-30  illustrates  this  point. 
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NOTE 


For  ease  in  making  calculations,  an  Excel  spreadsheet  application  can  be 
used.  Table  A- 5  provides  an  example  of  a  10-watt  transmitter  operating  at  1 
Mbps  in  L-band  and  S-band  using  the  formulas  in  the  spreadsheet.  The  Excel 
file  that  created  Table  A- 5  can  be  downloaded  here  and  used  for  interactive 
calculations. 


The  input  values  for  transmitter  output  power  and  bit  rate  are  in  the  cells 
highlighted  in  yellow.  The  amount  of  back-off  will  be  displayed  in  the  cells 
highlighted  in  light  blue.  Additionally,  each  telemetry  band  is  displayed  with 
the  useable  carrier  frequency  range  for  each  modulation  scheme  given  in  blue. 
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Table  A-5.  Valid  Center  Frequency,  Band  Edge  Back-Off 


Carrier  Power  or  EIRP  (dBm): 

40 

Input  Number 

Mask  floor  (at  this  nominal  TX  power): 

-65 

dBe 

Input 

Bit  Rate  (Mbps): 

1.00 

1.00 

1.00 

Number 

PCM/FM 

SOQPSK/EQPSK 

ARTM  CPM 

K  = 

-28 

-61 

-73 

m  = 

2 

4 

4 

Bit  Rate  (bps) 

1.00E-t06 

1.00E-t06 

1.00E-t06 

Mask  hits  floor  at  offset  of  (MHz) 

2.34 

1.10 

0.83 

Band-edge  baekoff  (MHz,  rounded  to  nearest  0.5  MHz) 

2.5 

1.5 

1 

Result 

Band  Edge,  Eower  (MHz) 

1435 

E- 

Band  Edge,  Upper  (MHz) 

1525 

Band 

Eower  eenter  freq.  at  this  bit  rate  (MHz) 

1437.5 

1436.5 

1436.0 

Upper  eenter  freq.  at  this  bit  rate  (MHz) 

1522.5 

1523.5 

1524.0 

Band  Edge,  Eower  (MHz) 

1755 

E- 

Band  Edge,  Upper  (MHz) 

1850 

Band 

Eower  eenter  freq.  at  this  bit  rate  (MHz) 

1757.5 

1756.5 

1756.0 

Upper  center  freq.  at  this  bit  rate  (MHz) 

1847.5 

1848.5 

1849.0 

Band  Edge,  Eower  (MHz) 

2200 

S- 

Band  Edge,  Upper  (MHz) 

2290 

Band 

Eower  center  freq.  at  this  bit  rate  (MHz) 

2202.5 

2201.5 

2201.0 

Upper  center  freq.  at  this  bit  rate  (MHz) 

2287.5 

2288.5 

2289.0 

Band  Edge,  Eower  (MHz) 

2360 

S- 

Band  Edge,  Upper  (MHz) 

2395 

Band 

Eower  center  freq.  at  this  bit  rate  (MHz) 

2362.5 

2361.5 

2361.0 

Upper  center  freq.  at  this  bit  rate  (MHz) 

2392.5 

2393.5 

2394.0 
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APPENDIX  2-B 

Properties  of  the  Differential  Encoder  Specified  in 
IRIG  Standard  106  for  OQPSK  Modulations 

B.l.  Introduction 

This  appendix  summarizes  a  study  of  the  differential  eneoder  originally  adopted  by  the 
US  DoD  ARTM  projeet  and  the  RCC  and  ineorporated  into  the  IRIG  106  for  FQPSK-B 
modulation.  The  study,  performed  by  Mr.  Robert  Jefferis  of  the  TYBRIN  Corporation,  was 
prompted  by  inquiries  from  industry  representatives  who  were  concerned  that  this  particular 
differential  code  was  not  associated  with  commercial  telecommunication  standards  and  the  fact 
that  manufacturers  had  experienced  confusion  over  correct  implementation.  The  study  results 
shown  in  this  appendix  prove  the  code  to  be  robust,  reliable,  and  applicable  to  SOQPSK-TG  as 
well  as  FQPSK-B  and  FQPSK-JR.^^ 

This  appendix  is  organized  along  the  following  structure.  Section  B.2  describes  the  need 
for  differential  encoding.  Section  B.3  explains  the  IRIG- 106  differential  code  for  OQPSK. 
Section  B.4  demonstrates  differential  code’s  invariance  with  respect  to  constellation  rotation. 
Section  B.5  shows  the  differential  decoder  to  be  self-synchronizing.  Section  B.6  reviews  the 
differential  decoder’s  error  propagation  characteristics.  Section  B.7  analyzes  a  recursive 
implementation  of  the  differential  code.  Section  B.8  describes  use  of  this  code  with  frequency 
modulator-based  SOQPSK  transmitters.  A  description  of  the  implementation  of  the  entire 
coding  and  decoding  process  can  be  seen  at  B.IO  to  this  appendix. 

B.2.  The  Need  For  Differential  Encoding 

Practical  carrier  recovery  techniques  like  Costas  loops  and  squaring  loops  exhibit  a 
troublesome  M-fold  carrier  phase  ambiguity.  The  following  paragraphs  provide  a  description  of 
ambiguity  problems  and  how  to  overcome  them. 

Figure  B-1  shows  a  simplified  quadriphase  transmission  system  that  is  one  of  the 
methods  recommended  for  transparent  point-to-point  transport  of  a  serial  binary  data  stream. 
Transparent  means  that  only  revenue-bearing  data  is  transmitted.  There  is  no  in-line  channel 
coding  nor  is  special  bit  pattern  insertion  allowed.  The  assumption  is  made  for  an  NRZ-L  data 
stream  containing  the  bit  sequence  b(nTb)  transmitted  at  rate  rt  =  1/Tb  bits  per  second.  For 
QPSK  and  OQPSK  modulations,  the  bit  stream  is  divided  into  subsets  e  containing  even- 
numbered  bits  and  o  containing  odd  numbered  bits.  The  transmission  rate  associated  with  the 
split  symbol  streams  is  rs  =  rb/2  symbols  per  second.  Symbol  values  are  converted  to  code 
symbols  by  the  differential  encoder  described  in  Section  B.3.  A  baseband  waveform  generator 
converts  the  digital  symbol  time  series  into  continuous  time  signals  suitable  for  driving  the 
vector  modulator  as  prescribed  for  the  particular  modulation  in  use.  Thus,  each  subset  modulates 
one  of  two  orthogonal  subcarriers,  the  in-phase  (I)  channel,  and  the  quadrature  (Q)  channel.  The 
modulator  combines  these  subcarriers,  creating  a  phase-modulated  RF  signal  S(t).  On  the 
receive  side,  demodulation  separates  the  subcarriers,  translates  them  back  to  baseband,  and 


FQPSK-JR  is  an  FQPSK  variant  developed  by  Mr.  Robert  Jefferis,  TYBRIN  Corporation,  and  Mr.  Rich 
Formeister,  RF  Networks,  Inc. 
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constructs  replicas  of  the  code  symbol  series  E’(nTs)  and  O’(nTs).  Decoding  reverses  the 
encoding  process  and  a  multiplexer  recreates  a  replica  of  the  bit  stream  b’(nTb). 


Most  QPSK  and  OQPSK  systems  employ  coherent  demodulation.  Figure  B-2  is  a 
simplified  diagram  of  commonly  used  modulation  and  demodulation  structures.  Note  the 
optional  single-bit  delay  shown  in  the  odd  symbol  path.  This  creates  the  significant  difference 
between  QPSK  and  OQPSK,  the  delay  being  inserted  to  create  OQPSK.  Practical  carrier 
recovery  techniques  like  Costas  loops  and  squaring  loops  exhibit  a  troublesome  M-fold  phase 
ambiguity  (M=4  for  QPSK  and  OQPSK). Each  time  the  demodulator  carrier  synchronizer 
phase  locks  to  the  modulator  local  oscillator  its  absolute  phase  relationship  to  the  local  oscillator 
contains  the  offset  term  p,  which  can  take  on  values  of  0,  +  n/2,  or  n  radians. 


Figure  B-2.  OQPSK  106  Symbol-to-Phase  Mapping  Convention 


The  delay  can  be  inserted  into  either  channel.  The  IRIG-106  convention  and  most  published  literature  regarding 
FQPSK  and  SOQPSK  indicate  the  delay  in  the  odd  (or  Q)  channel. 

Proakis,  J.  G.  and  M.  Salehi.  Digital  Communications.  5*  Edition.  Boston:  McGraw-Hill,  2008. 

The  initial  offset  angle  (j)  is  generally  unknown  and  uncontrolled;  it  is  tracked  by  the  carrier  recovery  circuitry  and 
the  symbol  timing  circuits  automatically  ignore. 
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The  symbol  detectors  have  insufficient  information  to  determine  which  phase  offset 
exists.  They  always  interpret  demodulator  output  with  the  assumption  that  P=0.  The  resulting 
constellation  axis  rotations  and  their  impact  on  demodulator  output  are  shown  at  Figure  B-3  and 
Table  B-1.  The  180°  rotation  is  symmetric.  The  Axis  (subcarrier)  assignment  is  unchanged  but 
the  sense  (polarity)  of  both  axes  gets  reversed.  The  90°  and  270°  rotations  are  asymmetric.  Axis 
assignment  is  swapped  and  one  axis  polarity  is  reversed  in  each  case. 


Table  B-1.  Constellation  Axis  Rotations 

Rotation 

+r 

+0’ 

0 

I 

Q 

71/2 

-Q 

I 

71 

-I 

-Q 

371/2 

Q 

-I 

B.3.  A  Simple  Solution  To  The  Carrier  Phase  Ambiguity  Problem 

Differential  encoding  has  been  used  to  work  around  the  carrier  ambiguity  for  many  years. 
For  phase  modulations,  source  data  is  coded  such  that  phase  differences  rather  than  absolute 
phase  coordinates  become  the  information-bearing  attribute  of  the  signal.  The  QPSK  and 
OQPSK  modulations  use  1  and  Q  independently,  with  each  channel  transporting  one  symbol 
stream.  Starting  with  the  first  binary  digit,  bit  0,  even-numbered  bits  form  the  sequence  {ek}  and 
odd-numbered  bits  form  the  sequence  {ok+i}  where  the  counting  index  is  changed  from  the  bit 
index  n  to  the  symbol  pair  index 

k^2n  kE  {0,2,4,6,...}  (B-1) 

Figure  B-4  illustrates  how  QPSK  modulators  process  bits  in  pairs  (dibits),  mapping  and 
asserting  time  coincident  symbol  phase  coordinates  {Ik,Qk).^^  Phase  state  changes  commence 
and  end  on  symbol  interval  timing  boundaries,  each  state  taking  on  one  of  four  possible  values  at 
detector  decision  instants;  however,  the  case  of  interest  is  shown  in  Figure  B-5. 


Rectangular  I  and  Q  baseband  waveforms  are  used  only  for  illustration. 
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-1 
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0(t) 
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PHASE  STATE: 


(1,1) 


time 


Figure  B-4.  QPSK  State  Timing 
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j 
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1 
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(1.0) 

(1.1) 
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(I.H 

(1.0) 

(0.0^  (0.0) 

(0.1) 

(1.1) 

1 

* 

i 

I— ► 

BIT  #: 


X(t) 


-1 


ff(t) 


-1 


PHASE  STATE:  0  1  2  3  4  S  .  .  . 


Figure  B-5.  OQPSK  State  Timing 


The  Q  channel  half-symbol  delay  causes  OQPSK  phase  trajectories  to  evolve  on  a  half¬ 
symbol  (bit)  rate  basis.  For  the  particular  cases  of  FQPSK  and  SOQPSK-TG,  carrier  phase 
either  remains  unchanged  or  changes  by  ±7i/4  or  ±n/2  radians  over  the  pending  bit  interval. 

The  OQPSK  inter-channel  delay  might  at  first  seem  a  difficult  complication  because  it 
creates  additional  ambiguity;  in  other  words,  the  receiver  must  resolve  relative  inter-channel 
delay;  however,  as  shown  below,  this  is  not  a  problem. 

The  differential  encoding  rule  adopted  in  IRIG-106  for  OQPSK  appears  in  Feher^^  and  is 
therein  attributed  to  Clewer^^  and  Weber. Bit  by  bit,  the  code  symbol  sets  {Ek}  and  {Ok+i)  are 
formed  with  the  Boolean  expressions: 


T 

c? 

© 

III 

(B-2a) 

^(A'+l)  —  ^k+\  ® 

(B-2b) 

Kamilo  Feher.  Digital  Communications:  Satellite/Earth  Station  Engineering.  Englewood  Cliffs:  Prentice-Hall, 
1983,  pp.  168-170. 

R.  Clewer.  “Report  on  the  Status  of  Development  of  the  High  Speed  Digital  Satellite  modem”,  RML -009-79-24, 
Spar  Aerospace  Limited,  St.  Anne  de  Bellevue,  P.Q.,  Canada,  November  1979.  Quoted  in  Kamilo  Feher.  Digital 
Communications:  Satellite/Earth  Station  Engineering.  Englewood  Cliffs:  Prentice-Hall,  1983. 

W.  J.  Weber  III.  “Differential  Encoding  for  Multiple  Amplitude  and  Phase  Shift  Keying  Systems.”  In  IEEE 
Transactions  on  Communications,  Vol.  COM-26,  No.  3,  March  1978. 
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Two  bits  are  coded  for  each  value  of  A:  in  a  two-step  process.  First,  the  even  symbol  Ek  is 
coded  with  current  bit  eu-  Then  the  next  bit,  Ok+i  becomes  current  and  the  odd  symbol  Ok+i  is 
computed.  In  each  code  set  the  exclusive-or  operator  is  applied  to  the  state  defining  variables 
just  like  binary  phase  shift  keying  (BPSK)  differential  encoding.  Unlike  BPSK  however,  the 
current  source  bit  and  the  most  recent  code  symbol  from  the  other  channel  determine  adjacent 
phase  transitions.  The  inverted  code  symbol  in  equation  B-2a  introduces  asymmetry  in  the 
equations.  Its  significance  will  become  evident  in  the  next  section. 

The  code  symbol  sets  [E]  and  {0}  are  applied  to  the  I  and  Q  channels  of  the  OQPSK 
modulator.  The  initial  assignment  of  {E}  to  either  7  or  2  can  be  made  arbitrarily;  however,  with 
this  code  definition,  once  the  choice  is  made  at  the  modulator,  decoding  will  fail  if  channel 
assignment  conventions  change  anywhere  during  the  transmission  or  decoding  processes.  Thus, 
the  assignment  convention  must  extend  to  the  physical  modulator  and  demodulator.  The  IRIG- 
106  assigns  1  to  the  physical  1  subcarrier  (also  known  as  the  “real”  or  “cosine”  subcarrier)  and  Q 
is  applied  to  the  physical  Q  subcarrier  (also  known  as  the  “imaginary”  or  “sine”  subcarrier).  In 
order  to  stress  this  assignment  convention,  IRIG-I06  expresses  equation  B-2  explicitly  in  terms 
of  the  1  and  Q  channel  variables: 

^ k  —  ®  Q(k-\) 

Q{.k  +  \)  =  ®  ^ k 


(B-3a) 

(B-3b) 


(B-3) 


Decoding  is  straightforward.  When  P=0,  /’=/,  and  Q’=Q,  inspection  of  the  following 
truth  tables  reveals  simple  decoding  instructions: 


Equation  B-3a 


Equation  B-3b 


Ik  Q(k-l)  G 

0  0  0 

0  1  1 

1  0  1 

1  1  0 


Q(k+1)  Ik  ^(k+l) 

0  0  0 

1  ^  •  Equation  B-3 

I  0  I  ^  decoding  equation 

0  I  I 

I  I  0 


=  (B-4a) 

0\+\  =  Q\+\®I\  (B-4b) 


(B-4) 


The  equations  at  B-3  may  not  convey  an  intuitive  sense  of  the  shift  from  absolute  phase 
states  to  phase  differences.  Extending  B-3a  backwards  in  time  by  substituting  B-3b  into  B-3a 
results  in: 

Ik  =G  ®(ok-i®Ik-2)=Ik-2®(^k  (B-5) 


Similarly,  for  the  next  bit  interval  the  results  are: 
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Qi+i  =0^,1®  (e^:  ©  Qt_i )  =  ©  e  J  (B  -  6) 

This  recursive  form  clearly  shows  that  on  a  bit-by-bit  basis,  the  current  and  most  recent 
bits  control  phase  trajectory  motion,  not  absolute  phase.  Note  that  B-5  and  B-6  do  not  define  the 
sign  of  a  phase  change.  Predictable  decoder  output  requires  that  two  additional  conventions  be 
established  and  maintained.  Boolean  logic  polarity  conventions  used  throughout  the  system 
must  be  consistent.  The  IRIG-106  assumes  positive  true  logic.  Finally,  sign  conventions  and 
channel  assignment  used  within  the  transmitter  (baseband  signal  generator  and  modulator)  and 
the  receiver  (demodulator)  must  be  constrained  to  produce  a  consistent  code  symbol-to-phase 
mapping  convention.  The  IRIG-106  convention  is  shown  in  Figure  B-2.  For  example,  if  {b} 
were  to  consist  entirely  of  logic  one  values,  i.e.,  a  run  of  Is,  the  differential  encoding  process  and 
mapping  convention  will  produce  the  phase  trajectory  shown  in  Table  B-2. 


Table  B-2.  Response  to  Run  of  Is 

n 

b(n) 

k 

Ik 

Qk-i 

Qk+l 

Phase  (deg) 

Phase  A 

0 

1 

0 

0 

0* 

225* 

1 

1 

1 

135 

-7i/2 

2 

1 

1 

1 

1 

45 

-71/2 

3 

1 

0 

315 

-71/2 

4 

1 

2 

0 

0 

225 

-7i/2 

5 

1 

1 

135 

-7i/2 

*  denotes  assumed  initial  conditions 

The  trajectory  spins  clockwise,  and  the  phase  is  retarded  by  90°  during  each  bit  interval. 
Obviously,  any  single  (unbalanced)  sign  change  and  any  change  to  the  mapping  convention  will 
alter  the  trajectory. 

B.4.  Immunity  to  Carrier  Phase  Rotation 

The  equations  at  B-3  and  B-4  are  invariant  with  respect  to  cardinal  constellation  rotation 
as  shown  in  the  following. 

Proof: 

The  P=0  case  is  decoded  correctly  by  definition  according  to  equations  B-5  and  B-6.  At  Table 
B-1,  when  P  =  there  is  no  axis  swap  but  the  decoder  is  presented  with 

I\  =  h 

Q' k+i  ~  Qk+i 


Decoding  will  progress  as  follows: 

Step  1.  Even  channel;  apply  equation  B-4a; 


^  FQPSK-B,  FQPSK-JR,  and  SOQPSK-TG  modulations  respond  to  a  run  of  Is  with  an  S(t)  that  is  ideally,  a  pure 
tone  at  frequency  k-rt/T  Hz.  This  is  referred  as  “lower  sideband”  mode.  Similarly,  a  run  of  zeroes  will  produce  a 
constant  anti -clockwise  trajectory  spin  and  a  tone  at  fcH-rb/4  Hz  (“upper  sideband”  mode). 
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k  =  I'k  ®  Q  ' k-l  —  ^k  ®  Qk-l  —  ^k  ®  Qk-l  —  ^k 

Step  2.  Odd  channel;  apply  equation  B-4b; 

O  k  +  \  =  Q  yt+l  ®I  k  —  Qk  +  \  ®  ^ k  —  Qk  +  \  ®  ^ k  —  ^k+l 

Thus,  symmetric  rotation  is  transparent  to  the  code.  When  P=7t:/2  the  decoder  sees  the 
following. 

I'k  —  Qk-l 
Q  k+\  ~  ^k 

Decoding  takes  place  in  the  same  sequence: 

Step  1.  Even  channel,  apply  equation  B-4a; 

-  ^'k  ®Q'k-i  =  Qk-l  ®h  -  h®  Qk-l  -  (^k-i 

Step  2.  Odd  channel,  apply  equation  B-4b; 

o  yt+i  =  Q  ®i  ^  ©  Qk-l  ~ 

In  this  case  the  bit  sequence  is  recovered  correctly  and  the  code  definition  coupled  with 
consistent  sign  conventions  automatically  compensates  for  the  asymmetric  rotation  by  reversing 
the  application  order  of  B-4a  and  B-4b.  As  a  result,  the  output  indices  are  shifted  back  in  time 
one  bit  period.  Asymmetric  rotation  causes  a  one-bit  delay  in  the  decoding  process.  Finally,  the 
same  result  is  seen  when  p=37i/2: 

I'k  =  Qk-l 
Q'k.i  =  h 

Step  1.  Even  channel;  apply  equation  B-4a; 

(^'k  =  I'k®  Q  'k-\  =  Qk-l  ®  Ik  =  Ik®  Qk-l  =  Ok-i 

Step  2.  Odd  channel;  apply  equation  B-4b; 

o  ~  Q  ©/  ^  ©  Qk-l  ~  I k  ®  Qk-l  ~  ^k 

In  all  cases  the  decoder  correctly  reproduces  the  original  bit  sequence.  Decoding  is 
instantaneous  for  symmetric  rotations  but  it  is  delayed  by  one  bit  in  2  out  of  4  possible 
asymmetric  rotation  startup  scenarios. 

The  need  for  consistent  function  assignment  now  becomes  clear.  Application  of  B-4b  to 
a  code  symbol  formed  with  B-3a  produces  the  complement  of  the  original  bit.  Eikewise, 
application  of  B-4a  to  a  symbol  coded  with  B-3b  inverts  the  result. 

At  this  point,  the  OQPSK  inter-channel  delay  ambiguity  mentioned  in  Section  B.2  has 
not  been  resolved.  The  roles  of  V  and  Q’  reverse  with  asymmetric  rotations  and  there  is  no  way 
to  determine  when  this  occurs;  however,  as  long  as  the  code  symbol  time  sequence  is  preserved 
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at  the  decoder  and  the  roles  of  V  and  Q’  do  not  get  reversed  in  terms  of  the  application  of  B-6a 
and  B-6b,  inter-channel  delay  is  transparent  to  the  code  with  respect  to  reconstruction  of  the 
original  data  sequence. 

B.5.  Initial  Values 

Equations  B-3  and  B-4  do  not  impose  any  implementation  constraints  on  initial  values 
when  encoding  or  decoding  starts.  To  confirm  this  it  is  assumed  that  hardware  power-up  (or 
initial  data  presentation)  may  cause  encoding  to  commence  with  either  channel.  It  is  further 
assumed  that  no  provisions  for  specific  initial  values  in  encoder  and  decoder  state  memories  have 
been  made.  If  coding  starts  with  1  (see  equation  B-3a),  the  first  code  symbol  will  be  computed: 

11-^0  II  “  ^0  ®  (S-i) 

where  (.)  denotes  an  unknown  initial  value  and  double  vertical  bars  denote  computed 
values  influenced  by  initial  values.  Encoding  equations  B-3a  and  B-3b  will  progress  as  follows: 

||2i||  =  Oi®||  4|| 

1^2  II  =  ^2  ®||2l|| 

The  initial  values  do  establish  the  absolute  sense  of  code  symbols  for  the  duration  of 
transmission;  but,  on  both  ends  of  the  process,  two  of  three  terms  in  every  equation  are  affected 
consistently  by  the  initial  value,  which  by  symmetry  has  no  effect  on  the  outcome  of  exclusive-or 
operations.  Obviously,  identical  results  occur  if  the  encoder  starts  with  Q.  Independent  of 
starting  channel  and  initial  value  then,  the  first  and  all  subsequent  adjacent  code  symbol  pairs 
contain  valid  state  change  information. 

Initial  decoder  values  can  produce  errors.  Again  starting  with  7,  and  using  equations  B-4a 
and  B-4b,  decoding  will  progress  as  follows: 

||e'o||  =  /'o®(e'i) 

o\  =  Q\®i\ 

It  is  seen  that  on  the  second  cycle  the  initial  value  of  the  decoder  has  been  flushed  out. 

At  most,  one  bit  will  be  decoded  in  error.  Similarly,  if  decoding  starts  with  Q,  output  will 
progress: 

IKII=e',®(/'o> 

Again,  only  the  first  decoded  bit  may  be  incorrect.  The  conclusion,  then,  is  that  initial 
values  can  produce  at  most  one  decoded  bit  error;  however,  there  is  another  source  of  startup 


If  for  some  reason  the  system  application  requires  that  one  can  determine  whether  a  specific  symbol  was 
originally  transmitted  via  I  or  Q,  then  this  code  is  not  appropriate. 
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errors  that  is  seen  as  an  initial  value  problem.  Section  B.4  showed  that  odd  phase  rotations  {nil 
and  37i/2)  cause  a  single  bit  delay  in  the  decoder.  Examining  this  further,  the  first  symbol  index 
value  will  be  =  0.  If  the  decoder  starts  with  equation  B-4a,  the  first  decoded  bit  will  be: 

If  the  decoder  starts  with  equation  B-4b  the  first  result  will  be: 

o:  =  e;©/' =/o©(e_i)  =  ||eo|| 

The  first  case  produces  the  aforementioned  delay.  The  decoder  emits  an  extra  bit.  The 
second  bit  emitted  is  actually  the  first  bit  of  the  sequence  reconstruction  and  is  still  subject  to  the 
single  initial  value  error  probability  of  startup  processing.  The  latter  case  does  not  produce  a 
delay;  it  only  presents  the  possibility  of  a  first  bit  decoding  error. 

B.6.  Error  Propagation 

Differential  encoding  incurs  a  bit  error  penalty  because  received  code  symbols  influence 
more  than  one  decoded  bit.  First  consider  a  single-symbol  detection  error  in  current  symbol  E’ 
that  is  labeled  Sk.  The  following  sequence  of  decoding  steps  shows  how  the  error  propagates. 
Since  the  E  channel  was  chosen  as  current,  decoding  starts  with  equation  B-4a.  The  single 
detection  error  creates  two  sequential  decoding  errors.  By  symmetry  we  can  state  that  the  same 
result  occurs  if  a  single  error  occurs  in  O’. 

=  terror 

b\+i  =  Qk+i®Sk  terror 
b'k+2  =  ®Q'k+i  =  bk+2  ^  correct 

Next  is  the  case  of  two  symbol  detection  errors  occurring  consecutively  on  E’  and  O’, 
i.e.,  detectors  emit  error  symbols  E’k=Sk  and  0’k+i=£k+i.  Starting  again  with  equation  B-4a 
yields: 

®  2(^1)  terror 

b\k^i)  =  ®£k^  ^  correct 

b  (k+2)  ~  ^  (k+2)®^(k+i)  ~  b(k+2)  ^  error 
b  (k+i)  ~  ^  (k+3)®^  (k+2)  ~  ^(i:+3)  ^  COrTCCt 

Two  consecutive  symbol  errors  produce  two  decoding  errors  but  the  errors  are  not 
adjacent.  The  conclusion  from  this  is  that  symbol  detection  errors  influence  no  more  than  two 
decoding  cycles,  i.e.,  the  maximum  error  multiplication  factor  is  2. 

B.7.  Recursive  Processing  and  Code  Memory 

Most  systems  reconstruct  the  original  bit  rate  clock  and  {Z?}  by  merging  {e’}  and  {o’}. 
For  a  variety  of  reasons,  designers  might  be  tempted  to  multiplex  {/’}  and  [Q’}  into  a  bit  rate 
code  symbol  sequence  [Bn]  prior  to  decoding;  however,  the  same  considerations  that  foster 
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desire  for  post-multiplex  decoding  are  likely  to  be  accompanied  by  loss  of  transmitted  code 
symbol  order,  i.e.,  loss  of  knowledge  whether  a  given  code  symbol  came  from  I  or  Q.  The 
question  arises  as  to  whether  {Bn}  alone  contains  enough  information  for  unique  decoding.  The 
answer  is  no,  and  the  proof  is  shown  below. 

Proof: 

A  decoding  function  can  be  derived  by  inspection  of  equations  B-5  and  B-6.  Equation 
B-5  can  be  rearranged  as  follows: 

~  ^k-i  ®  ^k-2 

Similarly,  from  equation  B-6  we  can  write 

Qk+i  =  0^+1  (B  -  8) 

Here  are  two  instances  of  a  seemingly  identical  recursive  relationship,  i.e.,  the  current 
code  symbol  is  the  difference  between  the  current  bit,  the  previous  bit,  and  the  inverse  of  the 
most  recent  code  symbol  from  the  current  channel.  We  can  consolidate  these  equations  by 
converting  to  post-multiplex  bit  rate  indexing,  i.e., 

5„=^„©Vi)®V2)  (B-9) 

from  which  we  can  immediately  write  the  decoding  function 

=  (B-10) 

On  the  surface  it  seems  that  equation  B-10  will  work;"'^^  however,  these  relations  involve 
two  differences,  rather  than  one,  and  therefore  introduce  superfluous  initial  condition 
dependence.  For  brevity,  only  the  pitfalls  of  B-10  are  examined  herein,  assuming  that  a  non¬ 
recursive  encoder  is  used.  From  startup,  decoding  will  progress  as  follows. 

Ill'll- I 

\\b\\\  =  \\b\\\®B\®W, 

||Z2'3|U||Z7'2||@b'3@b'i 


As  seen,  absolute  polarity  of  the  first  and  all  subsequent  decoded  bits  is  determined  by 
three  initial  values.  Absent  appropriate  side  information  for  selecting  initial  values,  the  post¬ 
multiplex  decoder  offers  a  50-50  chance  of  decoding  with  correct  polarity.  The  code  sequence 


The  interested  reader  is  left  to  confirm  that  equation  C-10  is  indeed  rotation  invariant. 
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defined  by  equations  at  B-3  has  a  two-symbol  memory.  Additional  symbols  do  not  provide  new 
information  regarding  the  trajectory  history.  Another  way  to  view  this  problem  is  to  note  that 
this  recursive  decoder  does  not  guarantee  preservation  of  symbol  order,  which  is  a  prerequisite  to 
reliable  decoding. 

B.8.  Frequency  Impulse  Sequence  Mapping  for  SOQPSK 

The  SOQPSKs  first  described  by  Hill'*^  and  Geoghegan'^'^  are  defined  as  special  cases  of 
CPM.  Since  1998,  at  least  two  manufacturers  have  exploited  the  fact  that  modem  digital 
waveform  synthesis  techniques  enable  direct  implementation  of  the  CPM  equations  with 
virtually  ideal  frequency  modulators  and  filter  impulse  responses.  A  generic  model  of  these 
implementations  is  in  Figure  B-6.  The  I  and  Q  channels,  per  se,  do  not  exist  in  this  transmitter. 
At  the  beginning  of  each  bit  interval,  impulses  from  the  bit-to-impulse  alphabet  mapper  direct 
the  impulse  filter/frequency  modulator  to  advance  the  carrier  phase  by  90°,  retard  it  by  or  90°,  or 
leave  the  phase  unchanged.  This  is  accomplished  with  a  ternary  alphabet  of  frequency  impulses 
having  normalized  amplitudes  of  {-1,0,1  This  stmcture  cannot  be  mapped  directly  into  the 
constellation  convention  of  a  quadriphase  implementation  because  there  is  no  way  to  control 
absolute  phase.  The  equations  at  B-3  can  be  applied  to  this  non-quadrature  architecture  via  pre¬ 
coding.  A  general  treatment  SOQPSK  pre-coding  is  contained  in  Simon. The  pre-coding  truth 
table  given  in  Table  B-3  applied  to  the  model  in  Figure  B-7  will  yield  a  phase  trajectory  history 
identical  to  one  generated  by  the  quadriphase  counterpart  of  Figure  B-2  using  the  equations  at  B- 
3;  however,  one  more  constraint  is  necessary  to  establish  compatibility  with  the  IRIG-106 
quadriphase  convention.  Table  B-3  assumes  the  stipulation  that  positive  sign  impulse  values  will 
cause  the  modulator  to  increase  carrier  frequency. 


liipulse  Series 
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Figure  B-6. 
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Table  B-3.  SOQPSK  Pre-Coding  Table  for  IRIG-106  Compatibility 

MAP  ttK  FROM  Ik 

MAP  aK+i  FRO 

VI  Qk+1 

h 

2k- 1 

Ik-2 

AO 

ttk 

Qk+l 

Ik 

Qk-l 

AO 

ttk+i 

-1 

X* 

-1 

0 

0 

-1 

X* 

-1 

0 

0 

+l 

X* 

+  l 

0 

0 

+l 

X* 

+l 

0 

0 

-1 

-1 

+  l 

-Till 

-1 

-1 

-1 

+l 

+iil2 

+l 

Hill,  “An  Enhanced,  Constant  Envelope,  Interoperable  Shaped  Offset  QPSK.” 

Geoghegan,  “Implementation  and  Performance  Results.” 

^^The  so-called  ternary  alphabet  is  actually  2  binary  alphabets  {-1,0}  and  (0,1 },  the  appropriate  one  chosen  on  a  bit- 
by-bit  basis  according  to  certain  state  transition  rules. 

Marvin  Simon.  “Multiple-Bit  Differential  Detection  of  Offset  Quadriphase  Modulations.”  IPN  Progress  Report 
42-151.  15  November  2002.  Jet  Propulsion  Laboratory,  Pasadena,  CA.  Retrieved  4  June  2015.  Available  at 
http://ipnpr.ipl.nasa.gov/progress  report/42- 15 1/15  lA.pdf. 
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-1 

-El 

-El 

-E7i/2 

-El 

-1 

-El 

-El 

-Till 

-1 

-El 

-1 

-1 

-E7i/2 

-El 

-El 

-1 

-1 

-nil 

-1 

-El 

-El 

-1 

-71/2 

-1 

-El 

-El 

-1 

-E71/2 

-El 

*  Note:  Does  not  matter  if  “X”  is  a  -e1  or  a  -1 
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Figure  B-7.  OQPSK  Transmitter  (With  Precorder) 


B.9.  Summary 

This  investigation  confirmed  that  the  differential  encoder  defined  in  the  equations  at  B-3 
is  entirely  satisfactory  for  SOQPSK,  FQPSK-JR,  and  FQPSK-B  systems  where  conventional 
coherent  demodulation  and  single-symbol  detection  is  used.  In  addition,  a  method  of  extending 
this  code  to  SOQPSK  is  presented  without  proof. 

Specifically,  the  following  has  been  shown. 

a.  When  accompanied  by  consistent  sign  conventions,  a  consistent  symbol-to-phase 
mapping  rule,  and  preservation  of  symbol  order,  the  OQPSK  differential  code  defined  in 
B-3  and  the  decoding  rule  defined  in  B-4  is  rotation  invariant  and  unambiguously 
reconstructs  the  original  data  bit  sequence. 

b.  Decoding  is  instantaneous. 

c.  Equations  B-3  and  B-4  do  not  require  attention  to  initial  values. 

d.  At  most,  two  consecutive  output  bits  will  be  in  error  after  carrier  and  symbol 
synchronization  is  acquired. 

e.  The  recursive  relations  in  equations  B-9  and  B-10  are  ambiguous  and  therefore 
unreliable. 

f.  The  code  exhibits  a  detection  error  multiplication  factor  of  at  most  two. 

B.IO.  System- Level  Software  Reference  Implementation  of  Differential  Encoder  Defined 
in  IRIG  Standard  106  for  FQPSK  and  SOQPSK  Modulations 

B.  10. a.  Introduction 

The  Matlab®'^’^  program  listings  below  provide  a  Matlab  function  “Desysdemo”  and  an 
execution  control  script  “runDEdemo”.  In  the  context  of  differential  encoding,  the  function 
provides  a  complete  system  simulation  including  a  differential  encoder,  an  ideal  vector 
modulator,  channel  phase  rotation,  demodulation,  the  functional  equivalent  of  an  ideal  single¬ 
symbol  sample  and  hold  detector,  and  a  decoder.  The  user  can  create  sample  data  vectors  or  use 
the  example  data  provided.  In  addition,  the  user  can  manipulate  the  initial  value  vectors  to 
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explore  all  possible  initial  value  and  demodulator  phase  rotation  combinations  of  the  quadriphase 
implementation  model. 

By  setting  the  variable  “style”  to  zero,  the  function  will  also  emulate  the  pre-coded 
frequency  modulator  architecture  required  for  SOQPSKs;  however,  the  initial  value  of 
transmitter  carrier  phase  is  hard-coded  at  45°.  This  was  done  to  avoid  proliferation  of  initial 
value  options  and  is  thought  to  be  an  insignificant  omission  because  it  does  not  affect  generality 
of  the  phase  rotation  options. 

This  material  assumes  that  the  user  is  familiar  with  Matlab  workspace  operation.  The 
program  relies  only  on  basic  Matlab  license  libraries.  No  special  toolboxes  or  blocksets  are 
required. 

B.lO.b. Matlab  Workspace  Operation 

The  user  should  place  the  script  (shown  below  in  Section  B.lO.c)  in  the  directory  of 
choice  and  make  that  directory  current  in  the  workspace.  In  order  to  execute  the  canned 
example,  the  user  needs  to  create  the  variable  “example”  in  the  workspace  and  set  its  value  to  1. 

Executing  the  script  “runDEdemo”  should  produce  the  output  displayed  in  Table  B-1. 


Table  B-1.  Script  “runDEdemo”  Output 

results  = 

Model:  Quadriphase  Vector  Modulator 

Demodulator  Phase  Rotation  =  0° 

Initial  States: 

Encoder 

Memory 

Encoder 

Channel 

Decoder 

Memory 

Decoder 

Channel 

(0,0) 

0 

(0,0) 

0 

Input  Bit 

TX  Phase 

RX  Phase 

Output  Bit 

Decoding  Error 

I 

225 

225 

1 

0 

I 

135 

135 

1 

0 

I 

45 

45 

1 

0 

0 

45 

45 

0 

0 

0 

135 

135 

0 

0 

1 

135 

135 

1 

0 

0 

135 

135 

0 

0 

1 

135 

135 

1 

0 

I 

45 

45 

1 

0 

1 

315 

315 

1 

0 

0 

315 

315 

0 

0 

0 

45 

45 

0 

0 

1 

45 

45 

1 

0 

0 

45 

45 

0 

0 

The  first  column  of  the  results  shown  above  is  a  replica  of  the  input  data  vector.  The 
second  column  shows  the  initial  value-dependent  evolution  of  transmitted  phase.  The  third 
column  shows  the  effect  of  any  non-zero  phase  rotation  chosen.  The  fourth  column  shows  the 
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decoded  output  bit  stream.  The  fifth  column  flags  decoding  errors  with  values  of  1 .  Certain 
combinations  of  phase  rotation  and  initial  values  will  produce  values  of  9  in  the  fourth  and  fifth 
columns;  results  of  this  nature  are  associated  with  cases  that  delay  the  output  decoding  process 
by  one  bit. 

Variable  definitions  and  implied  instructions  for  manipulating  the  runtime  options  can  be 
obtained  by  using  the  normal  Matlab  help  command  for  these  specific  programs. 

B.lO.c.  Script  For  Modules 

Electronic  copies  of  these  programs  have  been  provided  to  the  RCC  Telemetry  Group. 
The  script  for  the  modules  discussed  above  is  shown  on  the  following  pages. 
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%  Control  Script  'runDEdemo' ,  for  running  system  demonstration 
%  of  differential  encoder  and  phase  mapping  convention 
%  defined  in  RCC  standard  IRIG-106  for  FQPSK-B  modulation. 

%  This  version  extends  demonstration  options  to  the  pre-coder 
%  required  for  implementing  SOQPSK  with  frequency  modulators. 

o 

%  Each  example  run  requires  input  variables  in  the  Matlab  workspace: 

o 

% "example"  -  a  flag  to  run  with  user  supplied  data  vector  or  run 
%  the  example  data  set  that  consists  of  two  repetitions  of  a 
%  a  7-bit  pseudo  random  sequence ( 0=user,  l=example) 

% "data"  -  optional  user  supplied  binary  bit  sequence  (arbitrary 
length) 

% "rotation_choice"  -  pointer  to  demodulator  phase  rotation  options: 

%  1=0,  2=pi/2,  3=  pi,  4=3*pi/2 

% "initTX"  -  vector  of  binary  encoder  startup  values: 

%  initTX  (1)=  1st  of  two  encoder  code  symbol  memory  values (binary, 
arbitrary) 

%  initTX (2 )=  2nd  encoder  code  symbol  memory  value (binary,  arbitrary) 

%  initTX (3) =  starting  channel  for  encoder (binary,  0=1,  1=Q) 

% "initRX"  -  vector  of  binary  decoding  startup  values 

%  initRX(l)=  1st  of  two  decoder  state  memory  values (binary,  arbitrary) 
%  initRX (2 )=  2nd  decoder  state  memory  value (binary,  arbitrary) 

%  initRX (3) =  starting  channel  for  decoder (binary,  0=1,  1=Q) 

% "style"  -  l=quadriphase  transmitter  architecture  (FQPSK) 

%  0=frequency  modulator  transmitter  architecture  (SOQPSK) 

%  The  example  values  are: 

%  data=[l  1100101110010] 

%  rotation_choice=l 
%  initTX=[0  0  0] 

%  initRX=[0  0  0] 

%  style=l 

R.P. Jefferis,  TYBRIN  Corp.,  JULY,  2002 
SOQPSK  model  added  14JUL03 

This  version  has  been  tested  with  Matlab  versions : 5 . 2 ,  6 . 1 

%  ***  Sample  Input  Setup  *** 
if  example 

data=[l  1100101110010]; 

rotation_choice=l ; 

initTX=[0  0  0]; 

initRX= [0  0  0 ] ; 

style=l ; 

end 

%  ***  Run  the  Reference  Implementation  *** 

[test, delay] =DEsysdemo (data, rotation_choice, initTX, initRX, style) ; 

%  ***  Prepare  Screen  Output  *** 
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ROTATION=[0  90  180  270]; 
if  style 

results=sprintf (' Model :  Quadriphase  Vector  Modulator\n ' ) 
else 

results=sprintf (' Model :  Frequency  modulator  (SOQPSK)  model\n') 

end 

results= [results  sprintf (' Demodulator  Phase  Rotation  =  %3.0f 
degrees\n ' , ROTATION (rotation_choice) ) ] ; 

results= [results  sprintf  (' Initial  States:  Encoder  Encoder  Decoder 
Decoder\n ' ) ] ; 

results= [results  sprintf]'  Memory  Channel  Memory 


Channel\n ' ) ] ; 

results= [results  sprintf]' - 

- \n') ]; 

results= [results  sprintf]'  ]%d, %d)  %d  ]%d,  %d) 

%d\n\n  ' ,  .  .  . 

initTX  ]1 : 2) , initTX ]3) , initPX ]1 : 2)  ,  initPX ]3) )  ]  ; 
results= [results  sprintf]'  Input  TX  RX  Output  Decoding\n ' ) ] ; 

results= [results  sprintf]'  Bit  Phase  Phase  Bit  Error\n')]; 

re  suit  s=  [results  sprintf  ]  ' - \n  '  )  ]  ; 

for  n=l : length ]data) 

results= [ results  sprintf]'  %d  %3.0f  %3.0f  %d 

%d\n ' , . . . 

test ]n,  :  )  )  ]  ; 

end 

results 


%  _ END  OE  CONTROL  SCRIPT _ 

function  [result, delay] = 

DEsysdemo ]inbits, rotation_choice, initTX, initPX, style) 

%  Reference  simulation  for  Range  Commanders  Council  standard  TRIG  106- 
2000 

%  EQPSK-B  differential  encoding  and  phase  mapping  convention. 

o 

%  Input  arguments:  see  "help"  for  "runDEdemo"  script 
%  Output  arguments: 

% "result"  -  Mx5  matrix, M=number  of  input  bits, columns  contain: 

%  ]:,1) input  bit,  ]:,2)TX  phase,  ]:,3)RX  phase,  ]:, 4) output 

bit,  ] : , 5 ) status 

% "delay"  -  overall  encode/decode  process  delay  in  bits 

%  "TX"  prefixes  refer  to  transmitter/encoder  variables,  "RX"  prefixes 
%  refer  to  receiver/decoder  variables 
%  Robert  P.  Jefferis,  TYBRIN  Corp.,  July, 2002. 

%  SOQPSK  model  added  14JUL03 

%  This  version  has  been  tested  with  Matlab  versions:  5.2,  6.1 
numbits=length  ]inbits) 

■k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

o 

%  *  Transmitter  * 

■ki^-k'k'k'k'k'k'ki^'k'k'k'k'k'k'k'k'k 

o 
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%  ***  differential  encoder  (also  SOQPSK  pre-coder) **** 

%  encoder  memory  initial  values: 

%  [(last  I  ch .  code  symbol)  (last  Q  ch.  code  symbol)] 
TXlastSYM=initTX (1:2); 

%  point  encoder  to  either  I  or  Q  starting  channel (0=1) 
TXpoint=initTX (3 )  ; 
for  n=l:numbits 
switch  TXpoint 
case  0 

%TXlastSYM 

%  compute  "current"  I  channel  code  symbol 
TXnewISYM=xor (inbits (n) , -TXlastSYM (2 ) ) ; 

TXcodeSYM(n, : ) = [TXnewISYM  TXlastSYM ( 2 )] ;  %  new  phase 
coordinates ( I , Q) 

TXlastSYM ( 1 ) =TXnewISYM;  %  update  encoder  memory  state 
TXpoint  =  -TXpoint;  %  point  to  Q  channel  eq.  for  next  bit 
case  1 

%  compute  "current"  Q  channel  code  symbol 
TXnewQSYM=xor (inbits (n) , TXlastSYM ( 1 ) ) ; 

TXcodeSYM (n, : ) = [TXlastSYM(l)  TXnewQSYM] ;  %  new  phase 
coordinates ( I , Q) 

TXlastSYM ( 2 ) =TXnewQSYM; %  update  encoder  memory  state 
TXpoint=  -TXpoint;  %  point  to  I  channel  eq.  for  next  bit 
otherwise 

disp (' Invalid  Specification  of  Encoder  starting  channel'); 

end 

end 

%  ***  modulate  *** 
switch  style 

case  1  %  **  Quadriphase  vector  modulator  ** 

%  RCC  TRIG  106  FQPSK-B  phase  mapping  convention:  (I,Q) 
for  n=l:numbits 

index= floor ( 2*TXcodeSYM (n,  1 ) +TXcodeSYM (n,  2 ) )  ; 
switch  index 
case  3  %  [1  1] 

TXphase  (n) =45;  %  TX  phase  angle,  degrees 
case  1  %  [0  1] 

TXphase (n) =135; 
case  0  %  [0  0 ] 

TXphase (n) =225; 
case  2  %  [1  0] 

TXphase (n) =315; 
otherwise,  disp ('map  error') 
end 

end 

case  0  %  **  Frequency  modulator  w/pre-coder  ** 
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%  *  pre-coder  * 

%  map  code  symbol  sequence  to  frequency  impulse  series,  alpha (n) 
alpha=zeros ( 1 , numbits ) ; 

TXpoint=initTX ( 3 ) ;  %  in  this  mode,  points  to  start  index 
for  n=3: numbits 

if  TXpoint  %  Q(k-i-l)  map 

if  TXcodeSYM(n,  2) ==TXcodeSYM (n-2 , 2) 
elseif  xor (TXcodeSYM (n, 2 ) , TXcodeSYM (n-1 ,  1 )  ) 
alpha (n) =-l ; 
else 

alpha  (n) =1 ; 

end 

else  %  I (k)  map 

if  TXcodeSYM{n, 1) ==TXcodeSYM (n-2 , 1) 
elseif  xor (TXcodeSYM (n, 1 ) , TXcodeSYM (n-1 , 2 ) ) 
alpha (n) =1 ; 
else 

alpha (n) =-l ; 

end 

end 

TXpoint=~TXpoint ;  %  switch  to  complement  function  for  next  bit 

end 

%  convert  alpha  to  phase  trajectory 
lastTXphase=4 5;  %  initial  phase  of  S(t) 
for  n=l: numbits 

TXphase (n) =mod (lastTXphase+alpha (n) *90,  360)  ; 
lastTXphase=TXphase (n)  ; 

end 

otherwise 

end 

^  'k'k'k'k'k'k'k'k'k'k'k'k 
o 

%  *  Receiver  * 

S'  'k'k'k'k'k'k'k'k'k'k'k'k 
o 

%  ***  Demodulator  Phase  Rotation  *** 

ROTATE=[0  pi/2  pi  3*pi/2]; 
rotate=ROTATE (rotation_choice) ; 
for  n=l: numbits 
switch  rotate 
case  0 

RXphase (n) =TXphase  (n) ; 
case  pi/2 

RXphase (n) =mod (TXphase (n) +90, 360) ; 
case  pi 

RXphase (n) =mod (TXphase (n) +180,  360)  ; 
case  3*pi/2 

RXphase (n) =mod (TXphase (n) +  270,  360)  ; 
otherwise 
end 

end 
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%  ***  detector  *** 
for  n=l:numbits 

switch  RXphase(n) 
case  45 


RXcodeSYM (n,  : 
case  135 

)  =  [1 

1]  ; 

RXcodeSYM (n,  : 
case  225 

)  =  [0 

1]  ; 

RXcodeSYM (n,  : 
case  315 

)  =  [0 

0]  ; 

RXcodeSYM (n, : 

)  =  [1 

0]  ; 

otherwise 

end 

end 

%  ***  decode  and  reconstruct  data  bit  sequence  *** 

%  decoder  memory  initial  values: 

%  [(last  decoded  I  channel  bit)  (last  decoded  Q  channel  bit)] 
RXlastSYM=initRX(l:2)  ; 

%  point  decoder  channel  to  either  I  or  Q  starting  channel  (0=1) 
RXpoint=initRX ( 3 ) ; 
for  n=l:numbits 
switch  RXpoint 
case  0 

%  compute  "current"  decoded  I  channel  bit 
RXbits (n) =xor (RXcodeSYM (n, 1 ) , -RXlastSYM (2)); 
RXlastSYM=RXcodeSYM (n, : ) ;  %  update  decoder  state 

RXpoint  =  -RXpoint;  %  point  to  Q  channel  eq.  for  next  bit 
case  1 

%  compute  "current"  decoded  Q  channel  bit 
RXbits (n) =xor (RXcodeSYM (n, 2 ) , RXlastSYM ( 1 ) ) ; 
RXlastSYM=RXcodeSYM (n, : ) ;  %  update  decoder  state 

RXpoint=  -RXpoint;  %  point  to  I  channel  eq.  for  next  bit 

otherwise 

end 

end 

%  _  END  OF  TX  and  RX  Processing  _ 

■k'ki^'k'k'k'k'k'ki^'k'k'k'k'k'k'k'k'k 

o 

%  *  Assemble  Output  * 

■ki^-k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

o 

%  identify  delay  incurred  in  overall  process 
of fset=xcorr (inbits, RXbits ) ; 
of f set (1 : numbits-1 )  =  [ ]  ; 

[of f set, delay] =max (offset (1 :min (length (of f set)  ,  10)  ) )  ; 
delay=delay-l  ; 
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%  adjust  RX  output  bit  vector  to  compensate  for  delay, 

%  inserting  values  of  9  at  beginning  of  vector  to  represent 
%  artifact  bits  associated  with  asymmetric  rotation  cases 
checkbits=inbits ; 
if  delay 

newf ront=ones (1, delay) *9; 
checkbits= [ newf ront  inbits]; 
checkbits  (end-delay-i-1 :  end)  =  [  ]  ; 

RXbits (1 : delay) =9; 

end 

%  identify  decoding  errors  in  reconstructed  bit  stream 
xmsn_error=checkbits~=RXbits ; 
xmsn_error (1 : delay) =9; 

%  assemble  output  matrix 
result  (:, 1 ) =inbits ' ; 
result ( : , 2 ) =TXphase '  ; 
result ( : , 3 ) =RXphase  '  ; 
result ( : , 4 ) =RXbits ' ; 
result ( : , 5 ) =xmsn_error ' ; 

%  _ END  OF  FUNCTION  DEsysdemo _ 
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APPENDIX  2-C 


Telemetry  Transmitter  Command  and  Control  Protocol 


C.l.  Introduction 


This  appendix  provides  standards  for  commands,  queries,  and  status  information  when 
communicating  with  telemetry  transmitters  configured  with  communication  ports.  The 
commands  are  divided  into  two  categories  of  command  sets  as  follows. 


a.  Basic.  The  basic  command  set  contains  the  minimum  (required)  commands  for 
transmitter  control,  query,  and  status. 

b.  Extended.  The  extended  command  set  contains  optional  commands  that  may  or  may  not 
be  implemented  and  may  be  shown  as  references. 


C.2.  Command  Line  Interface 


C.2.a.  User  Command  Line  Interface 


This  interface  is  the  default  upon  power  up  of  the  transmitter.  Each  command  or  query  is 
ended  by  a  carriage  return  <CR>.  Information  returned  from  the  transmitter  will  be  followed  by 
a  carriage  return  <CR>  and  the  “>”  will  be  displayed  to  indicate  the  transmitter  is  ready  to 
receive  commands  or  queries. 


NOTE 


With  regard  to  this  standard,  it  is  assumed  that  a  carriage  return  <CR>  is 
followed  by  a  line  feed.  The  transmitter  will  return  the  “OK”  mnemonic  for 
each  command  that  is  accepted.  The  transmitter  will  return  “ERR”  for  a 
command  or  query  that  was  interpreted  as  an  error.  Verification  that  a  query 
was  either  accepted  or  found  to  be  in  error  will  be  the  response  to  the  query. 

All  commands  are  case-insensitive.  The  transmitter  will  operate  in  half-duplex 
mode  and  will  echo  typed  characters  to  the  command  terminal. 


In  addition  to  the  required  user  command  line  interface  items,  the  following  list  contains 
options  that  may  or  may  not  be  implemented. 

a.  Backspacing  to  correct  typed  errors. 

b.  A  character  input  to  recall  the  last  command  line.  The  character  followed  by  a  <CR> 
is  recommended. 

C.2.b.  Optional  Programming  Interface 

If  the  transmitter  is  not  commanded  or  queried  though  a  terminal  program  (human 
interface),  there  may  be  an  option  to  operate  in  half-duplex  mode  so  that  concatenated 
commands  can  be  sent  directly  to  the  transmitter  (bulk  transmitter  set-up).  If  this  option  is  used, 
the  transmitter  will  only  return  a  single  accepted  “OK”  response  if  the  entire  string  was 
interpreted  and  accepted.  When  concatenating  commands,  the  semicolon  is  used  as  the  delimiter 
for  each  command.  If  this  optional  programming  interface  is  implemented,  the  transmitter  will 
identify  the  semicolon  delimiter,  recognize  the  character  string  as  a  bulk  command,  and 
recognize  the  start  of  a  new  command  after  each  delimiter. 
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C.3.  Initialization 

Upon  successful  communication  initialization,  the  transmitter  will  provide  the  controlling 
terminal  with  (as  a  minimum)  the  manufacturer’s  name,  model  number,  serial  number,  and 
supported  IRIG-106  release  number.  Other  information  (such  as  information  on  firmware  and 
temperature)  deemed  appropriate  by  the  manufacturer  is  allowed.  This  information  will  be 
displayed  only  upon  a  successful  power  up  and  communication  initialization  of  the  transmitter. 
Should  an  unsuccessful  power  up  occur,  based  upon  criteria  of  the  transmitter  manufacturer,  the 
transmitter  shall  return  “ERR”  and  allow  only  the  RE(RES)  command  to  reset  the  transmitter 
(see  Subsection  C.4.b(9)). 

Upon  successful  communication,  after  a  power  up,  a  communication  connection,  a 
command,  or  a  query,  the  transmitter  will  send  a  carriage  return  followed  by  a  “>“  to  signify  the 
transmitter  is  ready  to  accept  commands  and  queries. 

C.4.  Basic  Command  Set 

C.4.a.  Basic  Command  Set  Summary 

The  basic  command  fields  use  a  minimum  two  characters  with  the  optional  capability  of 
using  a  maximum  of  four  characters.  If  possible,  the  longer  four-character  field  should  be  used 
to  add  intuitiveness  to  the  basic  command  set.  The  commands  in  the  basic  command  set  are 
shown  in  Table  C-1. 


Table  C-1.  Basic  Command  Set 

Command 

Function 

ER(EREQ) 

Sets  or  queries  the  carrier  frequency. 

MO(MOD) 

Sets  or  queries  the  modulation  mode. 

RA(RAND) 

Sets  or  queries  the  setting  of  data  randomization  (ON  or  OPE). 

RE 

Sets  or  queries  the  RE  output  (ON  or  OEE). 

QA(QAEE) 

Queries  the  status  of  all  basic  commands. 

VE(VERS) 

Queries,  at  a  minimum,  the  manufacturer’s  name,  model  number,  and  serial 
number  of  the  transmitter. 

SV(SAVE) 

Saves  the  current  set-up  of  the  transmitter  to  on-board  nonvolatile  random 
access  memory  (RAM). 

RE(RCEE) 

Retrieves  a  transmitter  set-up  from  on-board  nonvolatile  RAM. 

RE(RES) 

Resets  the  transmitter  to  a  known  configuration  or  restarts  the  internal  power- 
up  sequence. 

DS(DSRC) 

Sets  or  queries  the  data  source  (INT  or  EXT). 

CS(CEKS) 

Sets  or  queries  the  clock  source  (INT  or  EXT). 

ID(IDP) 

Sets  or  queries  the  internal  data  pattern  (one  of  five  possible  settings). 

IC(ICR) 

Sets  or  queries  the  internal  clock  rate. 

TE(TEMP) 

Queries  the  internal  temperature  (in  Celsius). 

PC(PEC) 

Sets  or  queries  PEC. 

ST(STC) 

Sets  or  queries  Space  Time  Coding. 
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C.4.b.  Commands:  Basic  Command  Set 
C.4.b(l)  Carrier  Frequency 

Carrier  frequency  is  set  or  queried  with  the  FR(FREQ)  mnemonic  as  described  below. 

a.  Set  Frequency.  Use  “FR(FREQ)  XXXX.X  <CR>“  where  XXXX.X  is  the  commanded 
frequency  in  MHz  in  0.5-MHz  steps.  If  the  command  is  accepted,  an  “OK  <CR>“  is 
issued  as  a  response. 

In  the  event  of  an  incorrect  commanded  carrier  frequency  (for  example  the  commanded 
frequency  is  out  of  the  tuning  range  of  the  transmitter),  the  transmitter  will  default  to  the 
currently  set  carrier  frequency  before  the  command  was  issued.  The  transmitter  will  then 
return  “ERR  ER(EREQ)  XXXX.X  <CR>“  where  XXXX.X  is  the  prior  frequency  set  in 
the  transmitter. 

b.  Query  Erequency.  “ER(EREQ)  <CR>“  queries  the  currently  set  carrier  frequency  and 
returns  “ER(EREQ)  XXXX.X  <CR>“  where  XXXX.X  is  the  current  set  frequency  in 
MHz. 

C.4.b(2)  Modulation  Mode 

Modulation  mode  is  set  or  queried  with  the  MO(MOD)  mnemonic. 

a.  Set  Modulation  Mode.  Use  “MO(MOD)  X  <CR>“  where  X  corresponds  to  the 

modulation  mode.  If  the  command  is  accepted,  an  “OK  <CR>“  is  issued  as  a  response. 


Command 

Modulation  Type 

MO(MOD)  0 

PCM/EM 

MO(MOD)  1 

SOQPSK-TG 

MO(MOD)  2 

ARTM-CPM 

MO(MOD)  6 

Modulation  off  (carrier  only) 

In  the  event  of  an  incorrect  commanded  modulation  mode,  the  transmitter  will  default  to 
the  previous  modulation  mode  and  return  “ERR  MO(MOD)  X  <CR>“  to  indicate  the 
error  and  the  current  modulation  mode.  The  “MO(MOD)  6”  command  turns  off  the 
modulation  for  carrier-only  mode.  Modulation  will  return  upon  a  new  commanded 
modulation  mode.  If  the  transmitter  is  in  single  mode,  only  single  mode  commands  are 
valid  and  the  above  error  response  will  be  sent  should  an  invalid  modulation  mode 
command  be  sent.  The  same  logic  applies  when  the  transmitter  is  in  dual  mode. 

b.  Query  Modulation  Mode.  “MO(MOD)  <CR>“  queries  the  currently  set  modulation 
mode  and  returns  “MO(MOD)  X  <CR>“  where  the  integer  X  is  represented  in  the  above 
table. 

C.4.b(3)  Data  Randomization 

Data  randomization  is  set  or  queried  with  the  RA(RAND)  mnemonic.  Eor  additional 
information  on  randomization,  see  Subsection  2. 3. 3. 4.  This  command  only  enables/disables  the 
randomizer  specified  in  Annex  A. 2,  Eigure  A. 2-2. 

a.  Set  Data  Randomization.  Use  “RA(RAND)  X  <CR>“  where  X  corresponds  to  a  1  or  0. 
If  the  command  is  accepted,  an  “OK  <CR>“  is  issued  as  a  response. 
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Command 

Randomization 

RA(RAND)  1 

On 

RA(RAND)  0 

Off 

NOTE 


When  FEC  is  enabled,  randomization  per  Section  D.6  should  be 
implemented.  If  RA(RAND)  was  enabled  prior  to  enabling  FEC,  it  will 
be  disabled  when  FEC  is  enabled.  The  default  state  for  RA(RAND)  will 
be  off  when  FEC  is  enabled. 


In  the  event  of  an  incorrect  data  randomization  command,  the  transmitter  will  default  to 
its  current  setting  and  return  “ERR  RA(RAND)  X  <CR>“  to  indicate  the  error  and  the 
currently  set  state.  If  FC(FEC)  is  enabled,  a  “RA(RAND)  1”  command  will  return  an 
ERR  RA(RAND)  1<CR>. 

b.  Query  Randomization  Mode.  “RA(RAND)  <CR>“  queries  the  currently  set 

randomization  and  returns  “RA(RAND)  X  <CR>“  where  integer  X  is  represented  in  the 
above  table. 

C.4.b(4)  RE  Output 

The  RE  output  is  set  or  queried  with  the  RE  mnemonic. 

a.  Set  RE  Output.  Use  “RE  X  <CR>“  where  X  corresponds  to  a  1  or  0.  If  the  command  is 
accepted,  an  “OK  <CR>“  is  issued  as  a  response. 


Command 

RF  Output 

RE  1 

On 

RFO 

Off 

In  the  event  of  an  incorrect  RE  output  command,  the  transmitter  will  maintain  its  current 
state  and  return  “ERR  RE  X  <CR>“  to  indicate  the  error  and  return  the  current  RE  output 
setting  for  the  transmitter. 

b.  Query  RE  Output.  “RE  <CR>“  queries  the  currently  set  RE  output  and  returns  “RE  X 
<CR>“  where  X  corresponds  to  the  numbers  in  the  above  table. 

C.4.b(5)  Query  All 

The  “query  all”  command  is  executed  with  the  QA(QAEE)  mnemonic. 

a.  Query  Transmitter  Configuration.  The  command  “QA(QAEE)  <CR>“  requests  the 
current  setting  of  all  basic  commands.  The  transmitter  response  will  contain,  as  a 
minimum,  the  following,  in  this  order: 


(1) 

Carrier  Frequency. 

[FR(FREQ)  XXXX.X]<CR> 

(2) 

Modulation  Mode. 

[MO(MOD)  X]  <CR> 

(3) 

Randomization  setting. 

[RA(RAND)  X]  <CR> 

(4) 

RF  Output  setting. 

[RF  X]  <CR>  OK<CR> 

(5) 

Data  Source. 

[DS(DSRC)  X]  <CR> 
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(6) 

Internal  Data  Pattern 

[ID(IDP)  X]  <CR> 

(7) 

Clock  Source 

[CS(CEKS)  X]  <CR> 

(8) 

Internal  Clock  Rate 

[IC(ICR)  XX.XXX]  <CR> 

(9) 

Internal  Temperature 

[TE(TEMP)  XXX]  <CR> 

(10) 

Eorward  Error  Correction 

[PC(PEC)  X]  <CR> 

(11) 

Space  Time  Coding 

[ST(STC)  X]  <CR> 

b.  Status  of  Other  Commands.  If  other  commands  are  implemented  in  the  transmitter 
beyond  the  basic  set,  a  complete  status  should  be  given  for  each  implemented  command. 

C.4.b(6)  Version 

The  “version”  command  is  executed  with  the  VE(VERS)  <CR>  mnemonic. 

a.  Query  Transmitter  Version.  “VE(VERS)  <CR>“  requests  the  current  version  of  the 
transmitter.  The  response  will  contain  (at  a  minimum)  the  following  information  about 
the  transmitter  and  in  this  order: 

( 1 )  Manufacturer  N  ame 

(2)  Model  Number 

(3)  Serial  Number 

b.  Eormatting  and  Delimiting  the  Eields.  It  is  left  up  to  the  transmitter  manufacturer  to 
format  and  delimit  the  above  fields  and,  if  chosen,  add  additional  information  to  the 
response. 

C.4.b(7)  Save 

The  “save”  command  is  executed  with  the  SV(SAVE)  mnemonic. 

Eor  “Save  Transmitter  Set-Up”,  “SV(SAVE)  X<CR>“  saves  the  current  settings  of  the 
transmitter  to  register  “X”  in  nonvolatile  memory  within  the  transmitter.  If  only  one  location  is 
available,  the  value  of  “X”  is  zero.  This  document  puts  no  limit  to  the  number  of  storage 
registers  as  this  is  limited  by  available  nonvolatile  memory. 

The  command  “SV(SAVE)  <CR>“  will  save  to  the  default  location  0. 

In  the  event  of  an  unsuccessful  save  command,  the  transmitter  will  return  ERR 
SV(SAVE)  X<CR>  to  indicate  the  error  and  no  save  function  will  be  performed. 

In  order  to  avoid  the  situation  of  fielding  a  flight  test  item  that  has  been  inadvertently 
programmed  to  use  internal  clock  and  data  sources,  the  transmitter  power  up  configuration  will 
always  have  the  clock  and  data  source  as  external.  In  addition,  when  saving  to  register  “0”  clock 
and  data  sources  will  always  be  set  to  external. 

C.4.b(8)  Recall 

The  recall  command  is  executed  with  the  RE(RCEE)  mnemonic. 

Eor  “Recall  Transmitter  Set-up”,  “RE(RCEE)  X<CR>“  retrieves  and  restores  the 
transmitter  set-up  from  register  “X”  in  nonvolatile  memory  within  the  transmitter.  Values  of  X 
start  at  zero.  The  “0”  register  location  should  be  used  exclusively  for  the  default  set-up,  which  is 
the  memory  location  that  is  loaded  during  power-up. 
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The  command  “RL(RCLL)  <CR>  will  recall  from  the  default  regitster  location  “0”. 

In  the  event  of  an  unsuccessful  recall  command,  the  transmitter  will  return  ERR 
RL(RCLL)  X<CR>  to  indicate  the  error  and  no  recall  function  will  be  performed. 

During  a  recall  operation  the  transmitter  will  always  set  the  clock  and  data  sources  to 
external  (see  Subsection  C.4.b(7)). 

C.4.b(9)  Reset 

The  transmitter  can  be  reset  with  the  RE(RES)  mnemonic. 


a.  Reset  Transmitter.  “RE(RES)  <CR>“  resets  the  transmitter  by  reinitializing  the 

transmitter.  The  transmitter  will  use  the  following  basic  settings  as  a  base  configuration. 


Transmitter  Setting 

Command 

Result 

Carrier  frequency 

[ER(EREQ)] 

Eowest  valid  frequency  within  the  tuning  range 

Modulation  mode 

[MO(MOD)] 

MO(MOD)  0,  PCM/EM 

Differential  encoding 

[DE  X] 

DE  0,  Differential  encoding  off 

Randomization 

[RA(RAND)  X] 

RA(RAND)  0,  Randomization  off 

RE  output 

[REX] 

RE  0,  RE  output  off 

Data  source 

[DS(DSRC)] 

DS(DSRC)  0  External 

Clock  source 

[CS(CSRC) 

CS(CSRC)  0  External 

Internal  Data  Pattern 

[ID(IDP)]  11 

[ID(IDP)]  11  PN11(2“-1) 

Internal  Clock  Rate 

[IC(ICR)] 

IC(ICR)  05.000  5  MHz 

Eorward  Error 
Correction 

[PC(PEC)] 

EC(EEC)  0,  Eorward  Error  Correction  is  off 

Space  Time  Coding 

[ST(STC)] 

ST(STC)  1,  Space  Time  Coding  is  on 

b.  Example  Command  Use.  The  Reset  command  would  be  used  if  resetting  to  a  known 
configuration  is  required,  communication  to  the  transmitter  could  not  be  established,  if 
commands  were  not  being  recognized,  or  if  some  other  unknown  transmitter  state  was 
experienced. 

C.4.b(10)  Data  Source 

Data  source  is  set  or  queried  with  the  DS(DSRC)  mnemonic. 

a.  Set  Data  Source.  Use  “DS(DSRC)  X  <CR>“  where  X  corresponds  to  a  1  or  0.  If  the 
command  is  accepted,  an  “OK  <CR>“  is  issued  as  a  response. 


Command 

Source 

DS(DSRC)  0 

External 

DS(DSRC)  1 

Internal 

In  the  event  of  an  incorrect  data  source  command,  the  transmitter  will  return  “ERR 
DS(DSRC)  X  <CR>“  to  indicate  the  error  and  return  the  currently  set  data  source  state. 

b.  Query  Data  Source.  “DS(DSRC)  <CR>“  queries  the  currently  set  data  source  and  returns 
“DS(DSRC)  X  <CR>“  where  integer  X  is  represented  in  the  above  table. 

c.  Saving  Data  Source.  See  Subsection  C.4.b(7)  regarding  saving  the  data  source  setting. 
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C.4.b(ll)  Clock  Source 

The  clock  source  is  set  or  queried  with  the  CS(CLKS)  mnemonic. 

a.  Set  Clock  Source.  Use  “CS(CLKS)  X  <CR>“  where  X  corresponds  to  a  1  or  0.  If  the 
command  is  accepted,  an  “OK  <CR>“  is  issued  as  a  response. 


Command 

Source 

CS(CEKS)  0 

External 

CS(CEKS)  1 

Internal 

In  the  event  of  an  incorrect  command,  the  transmitter  will  return  “ERR  CS(CLKS)  X 
<CR>“  to  indicate  the  error  and  the  current  clock  source  setting  for  the  transmitter. 

b.  Query  Clock  Source.  “CS(CLKS)  <CR>“  queries  the  currently  set  clock  source  and 
returns  “CS(CLKS)  X  <CR>“  where  integer  X  is  represented  in  the  above  table. 

c.  Example  Command  Use.  Internal  data  can  be  clocked  either  with  an  external  or  internal 
clock.  This  command  allows  the  user  to  clock  the  known  data  with  an  existing  external 
clock  or  select  the  internal  clock  for  more  flexibility. 

d.  Saving  Clock  Source.  See  Subsection  C.4.b(7)  regarding  saving  the  clock  source  setting. 
C.4.b(12)  Internal  Data  Pattern 

The  internal  data  pattern  is  set  or  queried  with  the  ID(IDP)  mnemonic. 

a.  Set  Internal  Data  Pattern.  Use  “ID(IDP)  X”  where  X  corresponds  to  the  internal  data 
pattern.  If  the  command  is  accepted,  an  “OK  <CR>“  is  issued  as  a  response. 

b.  Example  Internal  Data  Patterns.  Example  patterns  are  shown  below. 


Command 

Pattern 

ID(IDP)  9 

2*^-1 

(511  bits) 

ID(IDP)  11 

2''-l 

(2047  bits) 

ID(IDP)  15 

2*5-1 

(32767  bits) 

ID(IDP)  20 

220-1 

(1048575  bits) 

ID(IDP)  23 

223-1 

(8388607  bits) 

ID(IDP)  0000 

0x0000 

Eixed  repeating 

ID(IDP)  EEEE 

OxEEEE 

Eixed  repeating 

ID(IDP)  AAAA 

0101010 

Eixed  repeating 

ID(IDP)  XXXX 

OxXXXX 

Eixed  repeating 

The  minimum  supported  patterns  shall  be  PNl  1,  PN15,  and  AAAA.  Selection  of  which 
additional  patterns  to  implement  is  left  up  to  the  manufacturer.  If  an  error  occurs,  the 
transmitter  will  return  “ERR  ID(IDP)  X  <CR>“  to  indicate  the  error  and  return  the 
current  data  source  setting  for  the  transmitter. 

c.  Query  Internal  Data  Pattern.  “ID(IDP)  <CR>“  queries  the  currently  set  internal  data 
pattern  and  returns  “ID(IDP)  X  <CR>“  where  integer  X  is  represented  in  the  above  table. 
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d.  Example  Command  Use.  This  feature  can  be  used  for  system  characterization  and 
troubleshooting.  A  known  bit  pattern  can  be  used  to  test  and  characterize  telemetry 
systems  end-to-end  or  isolate  baseband  signal  problems  to  the  transmitter. 

C.4.b(13)  Internal  Clock  Rate 

The  internal  clock  rate  is  set  or  queried  with  the  IC(ICR)  mnemonic. 

a.  Set  Internal  Clock  Rate.  Use  “IC(ICR)  XX.XXX  <CR>“  where  XX.XXX  corresponds  to 
the  clock  frequency  in  MHz  and  is  used  to  clock  the  selected  internal  data  pattern.  See 
Subsection  C.4.b(12).  Actual  range  for  the  clock  frequency  is  left  to  the  manufacturer 
but  should  correspond  to  the  specified  useable  input  clock  frequency  range.  Resolution 
should  be  ±1  kHz.  Accuracy  for  the  internal  clock  is  left  to  the  manufacturer  but  should 
correspond  to  internal  values  for  the  transmitter.  If  the  command  is  accepted,  an  “OK 
<CR>“  is  issued  as  a  response. 

In  the  event  of  an  incorrect  command,  the  transmitter  will  identify  the  error,  default  to  its 
current  state,  and  return  “ERR  IC(ICR)  XX.XXX  <CR>“  where  “XX.XXX”  indicates  the 
current  clock  source  for  the  transmitter. 

b.  Query  Internal  Clock  Rate.  “IC(ICR)  <CR>“  queries  the  currently  set  internal  clock  rate 
and  returns  “IC(ICR)  XX.XXX”  where  XX.XXX  is  the  current  set  internal  clock  rate  in 
MHz. 

C.4.b(14)  Internal  Temperature 

Internal  temperature  is  only  a  query  with  the  TE(TEMP)  mnemonic. 

Using  TE(TEMP)  will  query  the  current  internal  temperature  of  the  transmitter  and 
returns  “TE(TEMP)  XXX”  where  XXX  is  the  temperature  in  Celsius. 

C.4.b(15)  Eorward  Error  Correction 

When  used,  EEC  is  set  or  queried  with  the  EC(EEC)  mnemonic.  If  EEC  per  Appendix  2- 
D  is  implemented  in  the  transmitter,  this  command  will  enable,  disable,  or  query  the  current 
setting. 

a.  Set  Eorward  Error  Correction.  Use  “EC(EEC)  X  <CR>“  where  X  corresponds  to  the 
table  below.  If  X=I,  then  the  command  structure  is  “EC(EEC)  I  xxxx  yy  <CR>“  where 
xxxx  corresponds  to  the  block  size  and  yy  corresponds  to  the  code  rate.  If  the  command 
is  accepted,  an  “OK  <CR>“  is  issued  as  a  response.  When  EC(EEC)  is  enabled, 
randomization  in  the  transmitter  [RA(RAND)]  shall  be  disabled. 


Command 

Source 

Block  Size 

Code  Rate 

EC(EEC)  0 

Disable 

EC(EEC)  1  xxxx  yy 

Enable/Block 
Size/Code  Rate 

1024  or  4096 

12  selects  1/2 

23  selects  2/3 

45  selects  4/5 

EC(EEC)  X 

Euture  Error  Correction  Code  Capability 

In  the  event  of  an  incorrect  EEC  command,  the  transmitter  will  return  “ERR  EC(EEC)  X 
<CR>“  to  indicate  the  error  and  return  the  current  EEC  setting  for  the  transmitter. 
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b.  Query  Forward  Error  Correction  Setting.  “FC(FEC)  <CR>“  queries  the  currently  set 
FEC  condition  and  returns  “EC(EEC)  0<CR>“,  when  EEC  is  disabled  and  returns 
“EC(FEC)  1  xxxx  yy”  when  EEC  is  enabled. 

c.  Refer  to  Appendix  2-D  for  additional  details  on  EEC  and  the  associated  randomization 
used. 

C.4.b(16)  Space  Time  Coding 

An  STC-enabled  transmitter  is  two  independent  transmitters  when  STC  is  disabled.  The 
command  prompt  indicates  which  transmitter  is  communicating  over  the  serial  port.  When  STC 
is  enabled  modulation  will  be  SOQPSK-TG  per  Appendix  2-E. 

a.  Set  Space  Time  Coding.  Use  “ST(STC)  X  <CR>“  where  X  corresponds  to  a  1  or  0.  If 
the  command  is  accepted,  an  “OK  <CR>“  is  issued  as  a  response. 


Command 

Space  Time  Coding 

Prompt 

ST(STC)  0 

Disable 

RE1>  or  RE2> 

ST(STC)  1 

Enable 

> 

b.  Query  Space  Time  Coding.  “ST(STC)  <CR>“  returns  “ST(STC)  X<CR>“  where  integer 
X  is  represented  in  the  table  above.  “STC  0”  is  associated  with  a  command  prompt  of 
RE1>  or  RE2>. 

c.  Independent  Commanding.  The  following  command  structure  allows  independent 
commanding  when  STC  is  disabled. 

•  Upon  issuing  an  “ST(STC)  0  <CR>“  command,  the  command  prompt  changes  from 
“>“  to  “RE1>“,  indicating  communication  with  the  transmitter  associated  with  RE 
port  1  (Xmtrl).  The  default  command  prompt  is  “RE1>“. 

•  To  change  to  the  other  transmitter,  issue  the  command  “RE2”  and  the  command 
prompt  changes  to  “RE2>“,  indicating  communication  with  the  transmitter  associated 
with  RE  port  2  (Xmtr2). 

•  Commands  apply  to  both  transmitters  independently. 

•  Issuing  “ST(STC)  I  <CR>“  returns  the  “>“  prompt  indicating  STC  mode  is  enabled 
and  commands  apply  as  they  would  to  a  single  transmitter.  At  the  “>”  prompt 
independent  control  of  each  transmitter  is  not  available. 

d.  Example  Command  Use.  The  examples  in  Eigure  C-1  illustrate  the  use  of  several 
commands  to  cinfugre  transmitter  parameters. 
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> 

transmiher  is  ready  to  receive  commands  or  queries 

>ST 

Queries  STC  mode 

>ST  1 

Responds  STC  is  enabled 

> 

transmiher  is  ready  to  receive  conunands  or  queries 

>ST0 

Disables  STC 

RF1> 

Responds  RF 1  is  ready  to  receive  conunands  or  queries 

RF1>MOO 

Sets  RFl  modulation  mode  to  PCM/FM 

RF1>ST  1 

Enables  STC 

> 

transmiher  is  ready  to  receive  conunands  or  queries 

>MO 

Queries  modulation  mode 

>MO  1 

Responds  modulation  mode  is  SOQPSK 

> 

transmiher  is  ready  to  receive  conunands  or  queries 

>ST0 

Disables  STC 

RF1> 

RF  1  is  ready  to  receive  conunands  or  queries 

RF1>FR  4450.5 

Sets  RFl  frequency  to  4450.5  MHz 

RF1>DS0 

Sets  RFl  data  soiuce  to  External 

RF1>CS0 

Sets  RF  1  clock  somce  to  External 

RF1>RF2 

Selects  RF2  to  receive  conunands  or  queries 

RF2> 

RF  1  is  ready  to  receive  conunands  or  queries 

RF2>MO  0 

Sets  RF2  to  PCM/FM  modulation  mode 

RF2>FR  4460.5 

Sets  RF2  frequency  to  4460.5  MHz 

RF2>DS  0 

Sets  RF2  data  source  to  External 

RF2>CS  0 

Sets  RF2  clock  somce  to  External 

RF2>MO  2 

Sets  RF2  modulation  mode  to  ARTM-CPM 

RF2>ST  1 

Enables  STC 

> 

transmiher  is  ready  to  receive  conunands  or  queries 

Figure  C-1.  Terminal  Window  for  STC-Enabled  Transmitter 


C.5.  Extended  Command  Set 

C.5.a.  Extended  Command  Set  Summary 

Although  the  extended  command  set  does  not  include  all  possible  commands,  its  use 
provides  a  standard  way  of  implementing  known  features  of  transmitters.  This  standard  will  be 
updated  at  appropriate  intervals  should  new  capabilities  arise.  Commands  in  the  extended 
command  set  are  shown  in  Table  C-2. 


Table  C-2.  Extended  Command  Set 

Command 

Function 

DP(DPOE) 

Sets  or  queries  data  polarity  (NORM  or  INV) 

RP(RPWR) 

Sets  or  queries  the  output  RE  power  (HI  or  EO) 

SP(SEP) 

Eow-power  consumption  mode,  sleep  mode 

VP() 

Variable  RE  power  command 

CP() 

Sets  or  queries  the  input  clock  phase 

DEO 

Sets  or  queries  differential  encoding  (ON  or  OEE) 

RZQ 

Sets  or  queries  RE  power  on/off  pin  polarity 
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C.5.b.  Commands:  Extended  Command  Set 
C.5.b(l)  Data  Polarity 

Data  polarity  is  set  or  queried  with  the  DP(DPOL)  mnemonic. 

a.  Set  Data  Polarity.  Use  “DP(DPOL)  X  <CR>“  where  X  corresponds  to  a  1  or  0.  Actual 
data  polarity,  when  referenced  to  the  input  clock,  does  not  need  to  be  known;  this 
command  either  inverts  the  incoming  data  or  does  not.  If  the  command  is  accepted,  an 
“OK  <CR>“  is  issued  as  a  response. 


Command 

Polarity 

DP(DPOF)  0 

Normal 

DP(DPOF)  I 

Inverted 

In  the  event  of  an  incorrect  data  polarity  command,  the  transmitter  will  maintain  its 
current  setting  and  return  “ERR  DP(DPOL)  X  <CR>“  to  indicate  the  error  and  return  the 
current  data  polarity  setting  for  the  transmitter. 

b.  Query  Data  Polarity.  “DP(DPOL)  <CR>“  queries  the  current  data  polarity  and  returns 
“DP(DPOL)  X  <CR>“  where  integer  X  is  represented  in  the  above  table. 

C.5.b(2)  RF  Power  (High/Low) 

High  output  power  or  low  output  power  is  set  or  queried  with  the  RP(RPWR)  mnemonic. 

a.  Set  RF  Output  Power.  Use  “RP(RPWR)  X  <CR>“  where  X  corresponds  to  a  1  or  a  0.  If 
the  command  is  accepted,  an  “OK  <CR>“  is  issued  as  a  response. 


Command 

Output  RF  Power  Level 

RP(RPWR)  0 

Fow 

RP(RPWR)  1 

High 

b.  Query  RF  Output  Power  Fevel.  “RP(RPWR)  <CR>“  queries  the  currently  set  output  RF 
power  level  and  returns  “RP(RPWR)  X  <CR>“  where  integer  X  is  represented  in  the 
above  table. 

In  the  event  of  an  incorrect  RF  power  command,  the  transmitter  will  return  “ERR 
RP(RPWR)  X  <CR>“  to  indicate  the  error  and  return  the  current  RF  power  setting  for  the 
transmitter. 

c.  Example  use.  The  low  setting  could  be  used  for  lab  testing  or  ground  checks  when 
transmitter  and  receiver  antennas  are  co-located.  The  high  power  setting  is  for  normal, 
over-the-air  telemetry  transmission. 

C.5.b(3)  Fow  Power  Consumption,  Sleep  Mode 

The  transmitter  can  be  placed  into  a  mode  of  low  input  power  consumption  with  the 
SP(SFP)  mnemonic. 

a.  Set  Fow  Power  Mode.  Use  “SP(SFP)  X”  where  X  corresponds  to  a  1  or  0  as  shown  in 
the  following  table.  If  the  command  is  accepted,  an  “OK  <CR>“  is  issued  as  a  response. 
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Command 

Source 

SP(SLP)  0 

Full  Qperation  Mode 

SP(SLP)  1 

Sleep  Mode 

Sleep  mode  powers  down  all  nonessential  circuitry  within  the  transmitter  to  reduce  input 
power  consumption.  Note,  in  order  to  return  from  sleep  mode,  the  transmitter  must 
monitor  and  recognize  the  SP(SLP)  0  command.  In  the  event  of  an  incorrect  command, 
the  transmitter  will  return  “ERR  SP(SLP)  X  <CR>“  to  indicate  the  error  and  the  current 
power  mode  setting  for  the  transmitter. 

b.  Query  Power  Mode.  “SP(SLP)  <CR>“  queries  the  power  mode  setting  and  returns 
“SP(SLP)  X  <CR>“  where  integer  X  is  represented  in  the  above  table. 

C.5.b(4)  Variable  Power  Mode 

The  transmitter  can  support  user-selectable  output  power  levels  using  the  VP  XX<CR> 
mnemonic. 

a.  Set  Variable  Power  Level.  Use  “VP  XX<CR>“  or  “VP  X<CR>“  to  set  a  range  of  RF 
output  power  levels  available  in  discrete  predefined  steps.  If  the  command  is  accepted, 
an  “OK<CR>“  is  issued  as  a  response.  In  the  event  of  an  incorrect  command,  the 
transmitter  will  return  “ERR  VP  XX<CR>“  to  indicate  the  error  and  the  current  variable 
power  level  for  the  transmitter. 

b.  Query  Variable  Power  Level.  “VP<CR>“  queries  the  power  mode  setting  and  returns 
“VP  XX<CR>“  where  integer  XX  is  represented  in  the  table  below. 

c.  Look  Up  Table.  The  actual  value  of  output  power  that  corresponds  to  “XX”  is  undefined. 
Each  manufacturer  will  provide  an  equation  or  lookup  table  that  defines  the  output  power 
as  a  function  of  “XX”. 


Command 

RF  Power  Level 

VP  XX 

Full  Power  (equivalent  to  RP  1) 

VP  (XX  -  1) 

Less  than  full  power 

VP  1  (orVPPOl) 

More  than  low  power 

VP  0  (or  VPP  00) 

Low  Power  (equivalent  to  RP  0) 

d.  Variable  Power  in  STC  Transmitters.  For  transmitters  with  STC  capability,  the  VP 
command  applies  to  both  transmitters.  When  STC  is  disabled,  output  power  for  each 
transmitter  can  be  independently  controlled  with  the  VP  command. 

C.5.b(5)  Input  Clock  Phase 

The  transmitter  can  support  user-selectable  input  clock  phasing  using  the  CP  X<CR> 
mnemonic. 

a.  Set  Input  Clock  Phase.  Use  “CP  X<CR>“  where  X  corresponds  to  a  1,  0,  or  A.  If  the 
command  is  accepted,  an  “QK<CR>“  is  issued  as  a  response.  In  the  event  of  an  incorrect 
input  clock  phase  command,  the  transmitter  will  return  “ERR  CP  X<CR>“  to  indicate  the 
error  and  return  the  current  input  clock  phase  setting  for  the  transmitter. 
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b.  Query  Input  Clock  Phase.  “CP<CR>“  queries  the  input  clock  phase  setting  and  returns 
“CP  X<CR>“  where  the  value  of  X  is  represented  in  the  table  below. 


Command 

Input  Clock  Phase 

Data  Transitions 

CPO 

0° 

Rising  Edge  of  Clock 

CP  1 

o 

O 

oo 

Palling  Edge  of  Clock 

CPA 

0°  or  180° 

Edge  with  greatest  margin  with  respect  to 
data  transitions 

C.5.b(6)  Differential  Encoding 

Differential  encoding  is  set  or  queried  with  the  DE  mnemonic.  Eor  additional 
information,  refer  to  Subsection  2. 3. 3. 1.1  and  0.  This  command  is  only  applicable  when 
modulation  mode  is  set  to  SOQPSK-TG  (MO  1). 

a.  Set  Differential  Encoding.  Use  “DE  X  <CR>“  where  X  corresponds  to  a  1  or  0.  If  the 
command  is  accepted,  an  “OK  <CR>“  is  issued  as  a  response. 


Command 

Differential  Encoding 

DE  1 

On 

DEO 

Off 

In  the  event  of  an  incorrect  differential  encoding  command,  the  transmitter  will  return 
“ERR  DE  X<CR>“  to  indicate  the  error  and  return  the  current  differential  encoding 
setting. 

b.  Query  Differential  Encoding.  “DE  <CR>“  queries  the  currently  set  differential  encoding 
status  and  returns  “DE  X  <CR>“  where  integer  X  is  represented  in  the  above  table. 

c.  Default.  When  switching  modulation  modes  the  differential  encoding  shall  be  switched 
appropriately.  Eor  example,  when  switching  from  SOQPSK-TG  to  PCM/EM,  the 
differential  encoding  will  be  set  to  off. 

d.  Manual  Control.  Eor  the  PCM/EM  and  ARTM-CPM  modulation  modes,  differential 
encoding  will  always  be  disabled  (off).  Eor  SOQPSK-TG  modulation  mode,  differential 
encoding  will  be  enabled  upon  selection  of  that  mode;  however,  the  user  can  exercise 
manual  control  of  differential  encoding  when  using  SOQPSK-TG  modulation. 
Additionally  if  either  PEC  or  STC  are  enabled,  differential  encoding  will  be  disabled. 

C.5.b(7)  RE  Power  On/Off  Pin  Polarity 

The  RE  power  on/off  pin  polarity  is  set  or  queried  with  the  RZ  mnemonic.  This 
command  sets  the  polarity  of  the  pin,  either  a  low  or  high  level,  to  enable  RE  power  output. 

a.  Set  RE  Power  On/Off  Pin  Polarity. 


Command 

RF  Power 

RZ(RPZ)  1 

On  when  pin  is  high 

RZ(RPZ)  0 

On  when  pin  is  low 

In  the  event  of  an  incorrect  RE  power  command,  the  transmitter  will  return  “ERR  RE 
X<CR>  X<CR>“  to  indicate  the  error  and  return  the  current  RE  power  setting. 
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b.  Query  RF  Power  On/Off  Pin  Polarity.  “RZ(RFZ)  <CR>“  queries  the  currently  set  RF 
power  status  and  returns  “RZ(RFZ)  X  <CR>“. 

c.  Default.  The  transmitter  will  initialize  in  the  RF  power  pin  polarity  on/off  “On  when  pin 
is  high”  setting. 

C.6.  Transmitter  Communication  Example 

A  typical  terminal  window  is  shown  in  Figure  C-2  for  clarity.  Transmitter 
communication  initialization  is  assumed. 


FR  14.^5. 5 

OK 

FR 
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ERR  DEO 
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ERR  MOD  0 
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ERR 
TE 
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g.\ 
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DEO 
R.4  1 
RF'  1 


Figure  C-2.  Typical  Terminal  Window 


C.7.  Non-Standard  Commands 


NOTE 


This  paragraph  is  reseryed  for  transmitter  commands  that  fall 
outside  of  the  commands  and  command  structure  discussed 
aboye.  Additions  to  this  section  will  be  made  as  non-standard 
commands  are  deriyed  and  found  applicable  to  this  standard. 


C.8.  Physical  Layer(s) 

The  aboye  command  sets  are  independent  of  the  physical  layer  oyer  which  the  commands 
are  transferred.  The  command  set  should  be  implemented  in  such  a  way  that  it  can  be  translated 
oyer  any  physical  layer  interfacing  with  the  transmitter. 

Should  a  three- wire  serial  interface  be  chosen,  it  should  be  compatible  with  EIA232 
(http://www.eia.org/).  The  intent  of  this  standard  is  not  to  force  complete  EIA-232  compliance; 
rather,  the  intent  is  to  establish  a  serial  communication  interface  with  the  transmitter  so  that  any 
terminal  program,  such  as  Windows®  HyperTerminal  or  Linux  Minicom,  can  be  used  to 
communicate  with  the  transmitter.  A  transmit- and-receiye  line  will  be  supplied  with  an 
associated  ground  return;  the  choice  of  connector  pin-out  is  left  up  to  the  manufacturer.  The 
serial  interface  will  operate  at  one  of  the  common  transfer  rates.  Typical  baud  rates  are  300,  600, 
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1200,  2400,  4800,  9600,  19200,  38400,  57600,  and  115200  baud.  The  default  shall  be  9600 
baud.  Should  operation  at  another  baud  rate  be  desired,  a  command  must  be  implemented  to 
accommodate  this  capability.  The  command  shall  have  the  form  BD(BAUD)  as  described 
below. 

a.  Baud  Rate.  Serial  communication  baud  rate  shall  be  set  or  queried  with  the  BD(BAUD) 
mnemonic. 

b.  Set  Baud  Rate.  Use  “BD(BAUD)  X  <CR>“  where  X  corresponds  to  a  number  (0-9)  in 
the  following  table.  If  the  command  is  accepted,  an  “OK”  <CR>“  is  issued  as  a  response. 


Command 

Rate 

BD(BAUD)  0 

300 

BD(BAUD)  1 

600 

BD(BAUD)  2 

1200 

BD(BAUD)  3 

2400 

BD(BAUD)  4 

4800 

BD(BAUD)  5 

9600 

BD(BAUD)  6 

19200 

BD(BAUD)  7 

38400 

BD(BAUD)  8 

57600 

BD(BAUD)  9 

115200 

c.  Query  Baud  Rate.  “BD(BAUD)  <CR>“  queries  the  set  baud  rate  of  the  transmitter  and 
returns  “BD(BAUD)  X  <CR>“  where  integer  X  is  represented  in  the  above  table. 

In  the  event  of  an  incorrect  baud  rate  command,  the  transmitter  will  return  “ERR 
BD(BAUD)  X<CR>“  to  indicate  the  error  and  return  the  current  baud  rate  setting  for  the 
transmitter. 

Communication  should  be  compatible  with  a  terminal  set-up  consisting  of  one  of  the 
above  baud  rates  with  8  data  bits,  1  stop  bit,  1  start  bit,  and  no  parity.  ASCII  characters 
will  be  transmitted  and  received.  No  hardware  or  software  handshaking  should  be 
implemented  and  connector  pin-out  is  left  to  the  manufacturer. 
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APPENDIX  2-D 

Low-Density  Parity- Check  Codes  for  Telemetry  Systems 

D.l.  Background 

The  LDPC  codes  presented  are  intended  to  decrease  error  probabilities  in  a  primarily 
noisy  transmission  channel  for  use  in  the  AMT  test  environment. 

The  LDPC  code  is  a  linear  block  code.  This  type  of  code  maps  a  block  of  k  information 
bits  together  with  a  codeword  (or  codeblock)  of  n  bits.  Think  of  a  linear  block  code  as  a  chunk 
of  input  bits  mapped  through  a  coder  to  a  longer  chunk  of  output  bits.  This  is  sometimes  called 
an  n-k  code.  When  k  bits  are  mapped  to  a  length  n  codeblock  there  are  2^  codewords;  however, 
there  are  2”  possible  codewords  composed  of  n  bits.  The  idea  with  error  correction  codes  is  to 
pick  the  2^  codewords  of  the  2"  total  possible  codewords  that  are  far  enough  apart  (in  terms  of 
Hamming  distance)  to  guarantee  you  are  able  to  correct  a  certain  number  of  errors. 

This  particular  version  of  LDPC  code  is  systematic,  meaning  the  transmitted  codeblock 
contains  duplications  of  the  bits  of  the  original  information.  It  is  also  a  quasi-cyclic  linear  block 
code,  meaning  the  construction  of  these  codes  involves  juxtaposing  smaller  cyclic  submatrices 
(circulants)  to  form  a  larger  parity  matrix,  all  through  linear  operations. 

This  code,  like  all  other  FEC  schemes,  requires  an  encoder  on  the  transmission  side  and  a 
decoder  on  the  receiving  side  of  the  telemetry  link.  The  codes  offer  much  higher  decoding 
speeds  via  highly  parallelized  decoder  structures.  This  FEC  code  can  only  be  coupled  with 
SOQPSK-TG/FQPSK-B/FQPSK-JR  modulation.  The  LDPC  code  itself  does  not  guarantee 
sufficient  bit  transitions  to  keep  receiver  symbol  synchronizers  in  lock  so  a  randomizer,  defined 
in  this  appendix,  is  required  when  implementing  this  FEC  code. 

Since  LDPC  is  a  block  code,  the  start  of  a  codeblock(s)  must  be  identified  in  order  for  the 
decoder  to  function  properly.  This  identifier,  known  as  the  attached  synchronization  marker 
(ASM),  provides  this  marker  and  also  aids  in  detection  at  very  low  values  of  Eb/No.  Differential 
encoding/decoding  normally  associated  with  SOQPSK-TG/EQPSK-B/EQPSK-JR  modulation  is 
NOT  required  and  should  be  disabled.  Phase  ambiguities  will  have  to  be  resolved  using  the 
ASM. 

D.2.  Code  Description 

The  LDPC  code  is  a  linear  block  code  with  options  for  {n,k},  where  n  is  the  length  of  the 
codeblock  and  k  is  the  length  of  the  information  block.  An  LDPC  code  can  be  entirely  defined 
by  its  parity  check  matrix,  H.  The  k  X  n  generator  matrix  that  is  used  to  encode  a  linear  block 
code  can  be  derived  from  the  parity  check  matrix  through  linear  operations. 

Code  rates,  r,  chosen  for  this  AMT  application  are  1/2,  2/3,  and  4/5.  Information  block 
sizes  {k)  are  1024  and  4096  bits.  Given  the  code  rate  and  information  block  sizes,  codeword 
block  sizes  are  calculated  using  n  =  k/r.  See  Table  D-l. 
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Table  D-1.  Codeblock  Length  per  Information  Block  Size 

Information  Block 
Length,  k 

Codeblock  Length,  n 

Rate  1/2 

Rate  113 

Rate  4/5 

1024 

2048 

1536 

1280 

4096 

8192 

6144 

5120 

The  kXn  generator  matrix  G  shall  be  used  to  encode  a  linear  block  code.  The  matrix  G 
can  be  derived  from  the  parity  check  matrix  H. 

For  each  {n,k}  in  Table  D-1  a  parity  check  matrix  H  is  constructed  from  size  M  xM 
submatrices  per  Table  D-2. 


Table  D-2.  Submatrix  Size  per  Information  Block  Size 

Information  Block 
Length,  k 

Submatrix  size  M 

Rate  1/2 

Rate  2/3 

Rate  4/5 

1024 

512 

256 

128 

4096 

2048 

1024 

512 

D.3.  Parity  Check  Matrices 

Given  the  {n,k}  in  Table  D-1,  there  are  six  parity  check  matrices  that  need  to  be 
constructed.  Section  3.3  in  CCSDS  standard  131. 1-0-2  (CCSDS  September  2007)  describes  how 
each  parity  check  matrix  is  constructed  and  is  repeated  here  for  clarity. 

TheH  matrices  for  each  code  rate  are  specified  below.  Im  is  the  MxM  identity  matrix 
(main  diagonal  is  I’s,  all  other  entries  are  0)  and  Om  is  the  zero  matrix. 
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Parity  Check  Matrices 


H 


1/2 


Om 

Im 

Om 

1m  ®ni 

M 

1m 

Om 

1m 

112  ©  1^3  ®  1^4 

M 

©Hg 

Om 

©  rig 

1m 

0 

1 _ 

Om 

Om 

Om 

1m 

Om 

H  2^3  — 

rig  ©  iijQ  ©  rijj 

1m 

1m 

1m 

Om 

1m 

1 M 

llj2  ©  llj3  ©llj4 

1m 

fls  ®  fie 

Om 

II2  ©  llg 

1m  ®ni 
YI2  ©  rij  © 


H 


4/5 


Om 

Om 

Om 

Om 

Om 

Om 

1I21  ©1I22  ©n23 

1m 

Hjj  ©Hjg  ©nj2 

1m 

llg  ©  lljQ  ©  lljj 

1m 

11V2 

1m 

n  24  ©  n  25  ©  n  26 

1 M 

lllg  ©lljg  ©II20 

1m 

llj2  ©11^3  ©llj4 

Permutation  matrix  rij  has  non-zero  entries  in  row  i  and  column  entries  are  defined  by  (i)  for  z  e  (o, . . . ,  M  - 1} 

=  ^  {{^k  +  1 M  J)  mod  4)  +  (4  (L4z  /  M  J)  +  z  )  mod  ^ 

where  0^.  and  are  defined  in  the  following  tables  for  the  submatrix  sizes  defined  in  Table  D-2  for  each  code  rate  and 
information  block  size. 
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Code  Rate  =1/2,  Information  Block  Size  =  1024,  M  =  512 


k 

Ok 

^k(0,M) 

^-t(3,M) 

1 

3 

16 

0 

0 

0 

2 

0 

103 

53 

8 

35 

3 

1 

105 

74 

119 

97 

4 

2 

0 

45 

89 

112 

5 

2 

50 

47 

31 

64 

6 

3 

29 

0 

122 

93 

7 

0 

115 

59 

1 

99 

8 

1 

30 

102 

69 

94 
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k 

Ok 

M0,M) 

1 

3 

108 

0 

0 

0 

2 

0 

126 

375 

219 

312 

3 

1 

238 

436 

16 

503 

4 

2 

481 

350 

263 

388 

5 

2 

96 

260 

415 

48 

6 

3 

28 

84 

403 

7 

7 

0 

59 

318 

184 

185 

8 

1 

225 

382 

279 

328 
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k 

Ok 

M0,M) 

m,M) 

1 

3 

59 

0 

0 

0 

2 

0 

18 

32 

46 

44 

3 

1 

52 

21 

45 

51 

4 

2 

23 

36 

27 

12 

5 

2 

11 

30 

48 

15 

6 

3 

7 

29 

37 

12 

7 

0 

22 

44 

41 

4 

8 

1 

25 

29 

13 

7 

9 

0 

27 

39 

9 

2 

10 

1 

30 

14 

49 

30 

11 

2 

43 

22 

36 

53 

12 

0 

14 

15 

10 

23 

13 

2 

46 

48 

11 

29 

14 

3 

62 

55 

18 

37 
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Code  Rate  =2/3,  Information  Block  Size  =  4096,  M  =  1024 


k 

Ok 

M0,M) 

1 

3 

160 

0 

0 

0 

2 

0 

241 

182 

35 

162 

3 

1 

185 

249 

167 

7 

4 

2 

251 

65 

214 

31 

5 

2 

209 

70 

84 

164 

6 

3 

103 

141 

206 

11 

7 

0 

90 

237 

122 

237 

8 

1 

184 

77 

67 

125 

9 

0 

248 

55 

147 

133 

10 

1 

12 

12 

54 

99 

11 

2 

111 

227 

23 

105 

12 

0 

66 

42 

93 

17 

13 

2 

173 

52 

20 

97 

14 

3 

42 

243 

197 

91 

D-7 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  2,  July  2017 


Code  Rate  =4/5,  Information  Block  Size  =  1024,  M  =  128 


k 

Ok 

M0,M) 

1 

3 

1 

0 

0 

0 

2 

0 

22 

27 

12 

13 

3 

1 

0 

30 

30 

19 

4 

2 

26 

28 

18 

14 

5 

2 

0 

7 

10 

15 

6 

3 

10 

1 

16 

20 

7 

0 

5 

8 

13 

17 

8 

1 

18 

20 

9 

4 

9 

0 

3 

26 

7 

4 

10 

1 

22 

24 

15 

11 

11 

2 

3 

4 

16 

17 

12 

0 

8 

12 

18 

20 

13 

2 

25 

23 

4 

8 

14 

3 

25 

15 

23 

22 

15 

0 

2 

15 

5 

19 

16 

1 

27 

22 

3 

15 

17 

2 

7 

31 

29 

5 

18 

0 

7 

3 

11 

21 

19 

1 

15 

29 

4 

17 

20 

2 

10 

21 

8 

9 

21 

0 

4 

2 

2 

20 

22 

1 

19 

5 

11 

18 

23 

2 

7 

11 

11 

31 

24 

1 

9 

26 

3 

13 

25 

2 

26 

9 

15 

2 

26 

3 

17 

17 

13 

18 
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Code  Rate  =4/5,  Information  Block  Size  =  4096,  M  =  5 12 


k 

Ok 

M0,M) 

1 

3 

16 

0 

0 

0 

2 

0 

103 

53 

8 

35 

3 

1 

105 

74 

119 

97 

4 

2 

0 

45 

89 

112 

5 

2 

50 

47 

31 

64 

6 

3 

29 

0 

122 

93 

7 

0 

115 

59 

1 

99 

8 

1 

30 

102 

69 

94 

9 

0 

92 

25 

92 

103 

10 

1 

78 

3 

47 

91 

11 

2 

70 

88 

11 

3 

12 

0 

66 

65 

31 

6 

13 

2 

39 

62 

19 

39 

14 

3 

84 

68 

66 

113 

15 

0 

79 

91 

49 

92 

16 

1 

70 

70 

81 

119 

17 

2 

29 

115 

96 

74 

18 

0 

32 

31 

38 

73 

19 

1 

45 

121 

83 

116 

20 

2 

113 

45 

42 

31 

21 

0 

86 

56 

58 

127 

22 

1 

1 

54 

24 

98 

23 

2 

42 

108 

25 

23 

24 

1 

118 

14 

92 

38 

25 

2 

33 

30 

38 

18 

26 

3 

126 

116 

120 

62 

D.4.  Encoding 

The  recommended  method  for  producing  codeblocks  consistent  with  the  parity  check 
matrices  is  to  perform  matrix  multiplication  (modulo-2)  by  block-circulant  generator  matrices. 
This  family  of  codes  supports  rates  KI{K+2),  where  K=2  for  a  rate  1/2  code,  K=A  for  rate  2/3,  and 
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K=S  for  rate  4/5.  Generator  matrices,  G,  have  size  MK  xM(K  +  3)  if  punctured  columns  are 
described  in  the  encoding.  (Note:  If  punctured  columns  are  omitted,  as  in  this  case,  G  will  have 
a  size  equal  to  MK  xM(K  +  2)).  Table  D-3  lists  the  size  of  G  for  each  information  block  size  and 
code  rate. 


Table  D-3.  Generator  Matrix  Sizes 

Information  Block 

Generator  Matrix  (G)  Size 

Length,  k 

Rate  1/2 

Rate  2/3 

Rate  4/5 

1024 

1024  X  2048 

1024  X 1536 

1024  X  1280 

4096 

4096x8192 

4096  X  6144 

4096x5120 

These  generator  matrices  may  be  constructec 

as  follows. 

1 .  Let  P  be  the  3M  x  3M  submatrix  of  H  consisting  of  the  last  3M  columns.  Let  Q  be  the 
3M  X  MK  submatrix  of  H  consisting  of  the  first  MK  columns. 

2.  Compute  W=(P-1Q)T,  where  the  arithmetic  is  performed  modulo-2. 

3.  Construct  the  generator  matrix  G=[IMK  W]  where  IMK  is  the  MK  x  MK  identity  matrix, 
and  W  is  a  dense  matrix  of  circulants  of  size  MK  x  M(N-K).  The  dimension  of  W  is 
MK  X  2M. 

Because  the  LDPC  code  is  systematic  and  the  generator  matrix  G  is  block-circulant,  an 
efficient  bit-serial  encoder  can  be  implemented  as  shown  in  Figure  D-7.  Initially,  the  binary 
pattern  for  the  first  row  of  circulants  is  placed  in  the  shift  registers,  and  the  accumulator  is  set  to 
the  length  2M  zero  vector.  The  contents  of  the  shift  registers  are  added  (modulo-2)  to  the 
accumulator  if  the  first  message  bit  is  a  1,  and  the  shift  registers  are  cyclicly  shifted  right  one 
place.  This  is  repeated  for  each  subsequent  message  bit  until  m=M/4  cyclic  shifts  have  been 
performed.  The  shift  registers  are  then  loaded  with  binary  patterns  for  the  next  row  of  circulants, 
and  the  process  continues  in  this  manner  until  all  message  bits  have  been  encoded. 


Figure  D-7.  Quasi-Cyclic  Encoder  Using  Feedback  Shift  Register 
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Computing  the  generator  matrix  G  involves  inverting  a  large  binary  matrix,  a 
computationally  demanding  task.  For  convenience,  G  for  each  information  bock  size  and  code 
rate  is  tabulated  here  in  a  compact  form. 

D.4.a.  Code  Rate  =1/2,  Information  Block  Size  =  1024,  M  =  5 12 

The  first  1024  columns  of  G  form  a  1024  x  1024  identity  matrix  and  the  remaining  1024 
columns  of  G  form  a  block  matrix  composed  of  16  rows  and  8  columns  of  circulant  matrices, 
each  of  size  128  x  128.  The  first  row  of  each  circulant  is  given  in  hexadecimal  format  in  Table 
D-4  according  to  its  location  in  G.  Subsequent  rows  of  each  circulant  can  be  computed  by 
applying  the  corresponding  number  of  right  circular  shifts  to  the  first  row. 


Table  D-4.  First  Rows  of  Circulants  in  Generator  Matrix,  r=l/2,  k=1024 

Row  1 

Columns  1025-1152 

CFA794F49FA5A0D88BB31D8FCA7EA8BB 

Columns  1153-1280 

A7AE7EE8A68580E3E922F9E13359B284 

Columns  1281-1408 

91E72AE8E2D6BE7830A1E83B3CDBD463 

Columns  1409-1536 

CE95C0EC1E609370D7E791C870229C1E 

Columns  1537-1664 

71EE3EDE60E2878478934DB285DEC9DC 

Columns  1665-1792 

0E95C103008B6BCDD2DAE85CAE732210 

Columns  1793-1920 

8326EE83C1EBA56EDD15B2DDB31EE7E2 

Columns  1921-2048 

3BA0BB43E83C67BDA1E6AEE46AEE4E62 

Row  129 

Columns  1025-1152 

565083780CA89ACAA70CCEB4A888AE35 

Columns  1153-1280 

1210EAD0EC9602CC8C96B0A86D3996A3 

Columns  1281-1408 

C0B07EDDA73454C25295E72BD5004E80 

Columns  1409-1536 

ACCE973EC30261C990525AA0CBA006BD 

Columns  1537-1664 

9E079E09A405E7E87AD98429096E2A7E 

Columns  1665-1792 

EB8C9B13B84C06E42843A47689A9C528 

Columns  1793-1920 

DAAA1A175E598DCEDBAD426CA43AD479 

Columns  1921-2048 

1BA78326E75E38EB6ED09A45303A6425 

Row  257 

Columns  1025-1152 

48E42033B7B9A05149DC839C90291E98 

Columns  1153-1280 

9B2CEBE50A7C2C264EC6E7D674063589 

Columns  1281-1408 

E5B6DEAEBE72106BA9E6676564C17134 

Columns  1409-1536 

6D5954558D23519150AAE88D7008E634 

Columns  1537-1664 

1EA962EBAB864A5E867C9D6CE4E087AA 

Columns  1665-1792 

5D7AA674BA4B1D8CD7AE9186E1D3B23B 

Columns  1793-1920 

047E112791EE97B63EB7B58EE3B94E95 

Columns  1921-2048 

93BE39A6365C66B877AD316965A72E5B 

Row  385 

Columns  1025-1152 

1B58E88E49C00DC6B35855BEE228A088 

Columns  1153-1280 

5C8ED47B61EEC66B5004EB6E65CBECE3 

Columns  1281-1408 

77789998EE80925E0237E570E04C5E5B 

Columns  1409-1536 

ED677661EB7EC3825AB5D5D968C0808C 
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Columns  1537-1664 

2BDB828B19593F41671B8D0D41DF136C 

Columns  1665-1792 

CB47553C9B3F0EA016CC1554C35E6A7D 

Columns  1793-1920 

97587EEA91D2098E126EA73CC78658A6 

Columns  1921-2048 

ADE 197 112081 86CA95C74 17  A 1 5690C45 

Row  513 

Columns  1025-1152 

BE9C169D889339D9654C976A85CED9E7 

Columns  1153-1280 

47C4 1 48E3B47 1 2D  AA3B  AD  1 AD7 1 873D3  A 

Columns  1281-1408 

1CD630C342C5EBB9183ADE9BEE294E8E 

Columns  1409-1536 

7014C077A5E96E75BE566C866964D01C 

Columns  1537-1664 

E72AC43A35AD216672EBB3259B77E9BB 

Columns  1665-1792 

1 8D  A8B09 1 94EA 1 E0E876 A080C9D6  A39E 

Columns  1793-1920 

809B168A3D88E8E93D995CE5232C2DC2 

Columns  1921-2048 

C7CEA44A363E628A668D46C398CAE96E 

Row  641 

Columns  1025-1152 

D57DBB24AE27  AC  A 1 7 1 6E8EA 1 B  8  AA 1 086 

Columns  1153-1280 

7B7796E4A86E1ED54C7576AD01C68953 

Columns  1281-1408 

E75BE799024482368E069658E7AAAEB0 

Columns  1409-1536 

975E3AE795E78D255871C71B4E4B77E6 

Columns  1537-1664 

65CD9C359BB2A82D5353E007166BDD41 

Columns  1665-1792 

2C54473 14DB027B  lOB  13007 1AD0398D 1 

Columns  1793-1920 

DE19BC7A6BBCE6A0EE021AABE12920A5 

Columns  1921-2048 

58BAED484AE89E29D4DBC170CEE1D369 

Row  769 

Columns  1025-1152 

4C330B2D11E15B5CB3815E09605338A6 

Columns  1153-1280 

75E3D1A3541E0E284E6556D68D3C8A9E 

Columns  1281-1408 

E5BB3B297DB62CD2907E09996967A0E4 

Columns  1409-1536 

EE33AEEE2C8A4A52ECCE5C39D355C39C 

Columns  1537-1664 

5EE5E09ABA6BCCE02A73401E5E87EAC2 

Columns  1665-1792 

D75702E4E57670DEA70B1C002E523EEA 

Columns  1793-1920 

6CE1CE2E05D420CB867EC0166B8E53A9 

Columns  1921-2048 

9DE9801A1C33058DD116A0AE7278BBB9 

Row  897 

Columns  1025-1152 

4CE0B0C792DD8EDB3ECEAE6E2B7E663D 

Columns  1153-1280 

106A1C296E47C14C1498B045D57DEEB5 

Columns  1281-1408 

968E6D8C790263C353CE307EE90C1E21 

Columns  1409-1536 

66E6B632E6614E58267EE096C37718A3 

Columns  1537-1664 

3D46E5D 1 0E993EB6DE8 1 5 1 8E8  85ED  A 1 B 

Columns  1665-1792 

6EE518ED48BB8E9DDBED4AC0E4E5EB89 

Columns  1793-1920 

BCC64D21A65DB379ABE2E4DC21E109EE 

Columns  1921-2048 

2EC0CE7B5D40973D13ECE713B01C6E10 

D.4.b.  Code  Rate  =1/2,  Information  Block  Size  =  4096,  M  =  2048 

The  first  4096  columns  of  G  form  a  4096  x  4096  identity  matrix  and  the  remaining  8192 
columns  of  G  form  a  block  matrix  composed  of  16  rows  and  8  columns  of  circulant  matrices, 
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each  of  size  512x512.  The  first  row  of  each  circulant  is  given  in  hexadecimal  format  in  Table 
D-5  according  to  its  location  in  G.  Subsequent  rows  of  each  circulant  can  be  computed  by 
applying  the  corresponding  number  of  right  circular  shifts  to  the  first  row. 


Table  D-5.  First  Rows  of  Circulants  in  Generator  Matrix,  r=l/2,  k=4096 


Row  1 

Columns 

4097- 

4608 

616DB583006DB99954780CD6DFC9908772D8260D390B1D462A8F62DE8809 

216194BE0531EE408AEAF27F50F3AD71865AC7910EEF8824A858CA7B13F 

C843DAEB1 

Columns 

4609- 

5120 

BA3E0B010860D09066A8632E2B273DABDE90C26ECDD989C2831874EA7E 

BA23D940A294111C1B0C1CE62E56A376B94CE64EA594B987B19226E52570 

4D7E2BC66E 

Columns 

5121- 

5632 

226C67 1C22A59AC062490596EB 1536C9E66AE799C2489EAD2C 13 1E29ED64 
A25CB0ADC88D04C5EC8EECD7E78B3825E626858CEAA0DE77772CE8822C 
7AA39628A0 

Columns 

5633- 

6144 

1 23B 1C426E2A93366D067D26DE5 1 362EA0B  A9 1 6EBD 1 22952  IB  1 B044459B3 
25785E3E3E24199B2460151E4CAA9ED26A5DC46BE0D6DA907EEAE38E413 
642E702E5 

Columns 

6145- 

6656 

324AED5D62E4CC25 1EE5C0ED95DE0EAB06 1 E0C92CA5BC97E976 1 1 8 AD84 
E0663A3BE1B4E07D1CCCC2DE9E09D506B073DED87CC0653C944EC7D438 
223C0DE3EB67 

Columns 

6657- 

7168 

E62AE13E8D4000D616E814045495E6E969C473B059386E5DDBCC25E4002E 

B 1 32D73  A984 14D85346E55DEBEE875E7CB9D2466A4 1 2D  1 80E0A 1  ADA  1 8D 
281376A671 

Columns 

7169- 

7680 

8EB0EB6BB7B9AD2A2 13201051 1077E6BD424B6E5B578C 1 1 D0076B7  8 1930E 
755EBB72C41ED17519476C257C31C3159BE31EADA2755E1B8A23B22D6A4 
28AA290E2 

Columns 

7681- 

8192 

54CC73C7599AB67C6807C4286BECE8423E3216EE04E1B6DE61349DDB23E 

3A0EB0EE70C5BE1AD91D31B0BB532C1098DC619BE80E3853EEA357091C 

05D95170A7E 

Row  513 

Columns 

4097- 

4608 

5E638 1 A7 1 8COA8 17E8 101ECDCDBE825E732E4356CEC42C222DBC476BD70 
4837C382B7EBE282B739EDC22B5EEA2909E0EB3ACB9E41EE2AC791130A3 
6A9CBEC1D9 

Columns 

4609- 

5120 

D4E8DE28EA77E37E4A6B5A82A58CE917CA74C8397E9DB8EDCB2BE65DB 

9 1954457707EE876DEE8 1 2D4B99466DE479A00 1 14E27E702249DB3E93 11301 
E9CE98703 

Columns 

5121- 

5632 

74EEAD0013ED861D67D7CE69D3635ECC6266E862D08B63077B45D3098306 
EA74 1 59DAEA2263E58705EA5  ABE5  8B7ED4 1 862B9EC IDOE 1 BD47CD6CB4 
2739C24E7EE 

Columns 

5633- 

6144 

7ACEE6D64C8E8E94BEABE280CEDCECEB26AC7330073C25E0313DCB75E 

6C5261E15D82AEA665E73A4B4DA4E5D1648EAB051EDEB9857C13C2E019 

ECBBA4E9DE2E1 

Columns 

6145- 

6656 

9CEEE1147D792C14AA2E211C3B9B94B2C9E24E49B0B1ED6E200C88D743E 

5AC1EE283C3A0AC79B9E1E496BDE74A2AA591ACE2E526EB24413A58B49 

5E91905E596 
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Columns 

D8F1469BCA9CC5041C50F1FB479CF2680503AD85BA2C0C6D01D2D739F3 

6657- 

129315E49A9F57236D9585CC0B8A9B4BFE9ADCD97BED9006C33976ACC0 

7168 

0468693D56EA 

Columns 

1EE66371B0EA6C4E1E172C2C5D76806CB7376B8CDEAD96B14A1EC2B656 

7169- 

298B9425EA2E0671082D70AA23C267D1E215C59239AEB40186DE0AB28462 

7680 

5DC6BAE45E 

Columns 

EBEBE26BED98BB3B697764A6E82C94039CBE14CB538A7D87801ACBD3A4 

7681- 

44A858BB74E0A4707592EE6B7DC6D21B8E6B4A184B567C8AA4CD825EBE 

8192 

7E1EDCE015A5 

Row  1025 

Columns 

25453670647D23C5E445A705953E3BE4A5AE02E7BC46C969C8141D8782E17 

4097- 

1C9CEE7EBB20945DE5D363AD36D3BD5A0BA081C079CDD04B6E5968187 

4608 

C8A665344A 

Columns 

23E9B1897A6EDE427B5E910AA8D71E9CC6351474BC4563C20ED38953295D 

4609- 

3BA15E7D1010503B7BA1C148251DB8A88AC64E6AE8C1CC056E4EEE1C92 

5120 

7EEC40C35D 

Columns 

57140969483D9E33429EAED177D031A43B727CE832C8DEEE8D8960CB55BE 

5121- 

4BE27B69CC26E2EB731B53250D6E8EE7DEDA98812B9AAE9C02AE2EEDE 

5632 

A598D6B6E2E 

Columns 

22B6CCA50541BD9E5D48565E551B310E10A0DECB8035A5EC86EB9CD8C8 

5633- 

11CDCBCCCEC3732EE93EE8C9418E25CA5744E07C45E9B161E277BCECE3 

6144 

88B9B84AAEC4 

Columns 

DA37EE277C72CB5CB1BE92AD373867403E46B3535159687ADC79C39DEE7 

6145- 

005C1E11E1CBD5E8877DA66AAC156EE27BB893E5E1132336D52E8AEB60E 

6656 

ACE9BEB3CE 

Columns 

D204D92DEA496DAE564272E3EEC51CE53C8E2DE6ACB191E60E14CDEA28 

6657- 

ED5ED0EBE09672ED11A3E6466EE3A967A4EC8390303059AE00DD83102A9 

7168 

E33B2943E4E 

Columns 

6E56928E7EEE3333A36EE3EE7598744CE7C298EEE3EACC7CCC0E36DCBA6 

7169- 

D87BDD44 108 1 1 63 A65E27C958 AE79C33  A98B  8181401 5E77E82EE5 1 20EBDA 

7680 

B540893B4 

Columns 

7BEB68CC37E23835C91E5D36D6BA6E0A5E68EEBB6E6A2E247EB5CE57684 

7681- 

D0770249460788DEDC4A1218652BE881B4BB06308EE86484E7070AACC72D 

8192 

3977CE5D0 

Row  1537 

Columns 

6230DEE1ACD4425E7B155A2A285CB2A32CB9D46DA09B28167826E77AEB 

4097- 

D85E0C416595E136184841451E5B3E1E17D02C3DB32C2AE50091D6376406D 

4608 

8CB78A9E3 

Columns 

D3B19911ACC450679EAE25B0E290EE372300E1A4BC91A43CB79DB270133 

4609- 

D41DC4970E1420E71C0E816EE938C3C17E0ECBB6E920ED853EAE6D2DC67 

5120 

92BE87098A 

Columns 

B94C2E5DDE78C974AD6E423CD5ACA01EC9420AAE3EE83BEC31D47AAC 

5121- 

D3D62EA2476C38595BD66639368181E75B44BAA7ADBC2B42E1D82D7A59 

5632 

312BB9A16E7D35 
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Columns 

OB  1 3B44D82807 1E69DD90DCD9B7 1 3  A05FD8C2 1 AA5E6E6D8DA49A5C3B3 

5633- 

4E98A4E5E822513E0DA200235C65BECA1DC2CE4AB21D146B778E6806680 

6144 

B8AC75285760 

Columns 

EEE66B861AA67C768A76D585DEADC8EB6556AD841DEA9E44ACB42B601 

6145- 

6142B6B69E1833474EADEB0400CE4D9E3BD62AD96E57E3E93DD229180E2 

6656 

D4B5E77D098E 

Columns 

EEBE2DEA4D4D86ECB07EEE9565EB589855E1E53BA1B9784A8D195A0E37 

6657- 

21551270089C535216636EBEB4D9E50A9EAC3DCB27891A7005A2AD87427 

7168 

E6B8326E6B3 

Columns 

CA225C7B2A9EABEEDDDBC130B5342917848B029917BA98EED6EE238900 

7169- 

6A6B417E678C61458EE625C96C0D3D07945ABB9836CE80823EB6244D86D1 

7680 

14CC5DC2B1 

Columns 

94E5D55C398B16A71497C4CE102C2E1035C19D5DEC8A301B8DE33D41D90 

7681- 

9C 1 5  A3093B09E7489CE6AA 14B33 1 B70E76637EE6DDEEEA6DC4C5 1 037 1C 

8192 

B0D2A6EA3DA 

Row  2049 

Columns 

AC5E866DD75CD4C2D5959AC37DE4E1E870313A5B2902E234CD939EE39E3 

4097- 

1EEBE8B46DAC906E3EBA9C3A74DE46E7A9140D3716667BB1EC22A87D5E 

4608 

8D048BDC5BA 

Columns 

57B6024327CDDEE3296BE6508C48045B71EA519156E8C125E4E3B7356576E 

4609- 

32C63BC588908C4E8B3E9E2D12A9E8E35B6ECE296C17ED8E8D076406EA11 

5120 

D16175E 

Columns 

CC45AE82D672979E8A0A359B2328C79AE61E87EBE04DAC93430305486597 

5121- 

32000CE627417B3E8CED4A992E7E2B680216AE773385B9337E1743D43ED96 

5632 

5282CE5 

Columns 

AE71B0CAEEB4DA3E0B95E1341667C519EB9E89D7CEC711E57485E04A965 

5633- 

CDC832CBEC0BE1B2A3E23B5EAE4C5DAD8767E054B2225A60B88BE1DB6 

6144 

A35E0BAEB237 

Columns 

A206BC721B252D52EA1E8E311203DEE0AE8D65BD1986055701A3C7EEB2D 

6145- 

DEDD2D57C3BBA6A2BC56A9157677D7B48AD2907927176E6B22E8A92E6E 

6656 

9863C9E16D9 

Columns 

11B6209E06EEE6ACBBBA2214EE5AEAB9D76645476B2C16B8D14E1AE3E3 

6657- 

A85188835922B914D3E32EE05B7987A2516B3D3C8983AE176DED04349A45 

7168 

359B422E1E 

Columns 

01CC2266E2B68A4323E8931D7AA37B1CBD70DC2EEE91592327207AA6121 

7169- 

795150A0DC918704A1A293778EE75A99EDCE77E820D0905EE7AC72A682E2 

7680 

487A6E0EE 

Columns 

03E42D94EDE1C13E958DE61 1 12DB4A27A8A8EE35087ED089729E0864C270 

7681- 

6CCB2B6CBD91A9A7B7B31E08EA3570A6E1BED495EC84EACD829E3234B 

8192 

1D1DC574B67 

Row  2561 

Columns 

900AA496432959141795C615CBAEA98002440A0D447EE990435E452CC6902 

4097- 

03BDEBCBA3EEEC7A7CE71EB54B1728AEA9EDE70A7E6A1A8AE8616870 

4608 

9A899738CCB 
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Columns 

C5B7A094AEBEA8EC95A414A8DE5D3DBE6745CB0D330B78435AC2BB666 

4609- 

6BB2D43A19EAD3B3D9536D0BB92DB949570981C22805E7DEA452EA649C 

5120 

84EDC4324A7EB 

Columns 

E6A9CAE4EE48400720B8E84CAC3A42483B7E571846E2A5E77A983EE31 1 17 

5121- 

9CEC2D99878EE5AA06ACA0CBBA63B36985E0970761E7E837650BC46C9A 

5632 

2EB1AEEA95 

Columns 

AC4D8AA5C970BB55EDE3408356C9EB2683B6EEE593736B66B49C055BD65 

5633- 

03EEE3C7CADD15C9B86DCA626E1ABE4B971D04C0A9A5AEE8305C3D0E4 

6144 

CC02C32EA91E 

Columns 

D8949EE8EEADE7DA39D395B52D2779A0B305C4ED10C33A434878967D932 

6145- 

1B4835C035CA5802C37E6DC 1E39AC30337253 1 14176BBB265763 17C72E954 

6656 

8E179A5A 

Columns 

A200EC35B6A0934D57543A60E6114B7B0D78D8DD8932538E545D806A1D9 

6657- 

E47390E092501E4A470CE7B1E9144D0A8E1B0C3D607930A75E5A150233DC 

7168 

EEDB4C10B 

Columns 

217C8EB38D4D2A0EE12557321D504ECA670B41E496441EDE341E0232101D 

7169- 

4E3E4158EE6E4EAECC073AA811DD450E528BC6095868B7BE953926056BD4 

7680 

09E5EE36 

Columns 

B82831B150B80A736D6CE7B16660ADCD5E1E4DB96E36E33DCC2E1506C7 

7681- 

B8B0E2A4EC362EB0CE7B8B3B08D6CD1AE7440729D4C3C02627AD8733A0 

8192 

C94B2EBAE526 

Row  3073 

Columns 

EDB4463E6E8EBAE565B1C3320E5704A87309E529842378ECB733784E1CBD 

4097- 

85E4E87EB0525C7C4D307061E74DE2EB3BDEBC77E04EAB75A64EEE51203 

4608 

AB925E807 

Columns 

ID  1 10 1 A 1 6A2C4 IDBDC  A94C 1 28560BEEDA4EC  A6E22B44C6E5085 A23E84 1 

4609- 

06E4ED870EAA789E03EC37086E67B69EC8EB6421AA57EBA27866DEE712D 

5120 

5EEDA21EC51 

Columns 

76EE3CB2C4A8629C20EC646A7ADE2A4BE73DCEE53EC926067EB9964996 

5121- 

BCEE403C5642CD2E8084E0C14D3627EAD9E0180DADE07331246C007E3AE 

5632 

95CC9B451CC 

Columns 

3638887EB493E5EE3361E07E00E115BC04AE404BE6BA3467322B37A8E6AB 

5633- 

E477 10D56C3BC75 1 892CED 1 2E29CC43 1 9D0562005562D0526 1D39EDE528 A 

6144 

11E65BBE 

Columns 

A0BE07C52E9A9ED7AC3E0EB9196A450E162009509E20BEE74ECC6316BC4 

6145- 

824D93CBAC25E470A7468A629EB520E980DE31E8C8873E4ED21B57AAEB 

6656 

E43A5754359 

Columns 

CD089ABE548975678C2 1 23223CE3E345 AE0CECE0A3726BEBB 1 30E34 1 69A 

6657- 

874B6C4CDEEC0A05D7DA1EE475E5407E1535399086700874C13000E2EE21 

7168 

DE3EEEB65 

Columns 

4BEE6E2B4137DC6EE197D514E904B8E31BAD6C846D6BD7D7480E4818C3C 

7169- 

57B4C7E53E168E48020273702071EE48EC53422C71C90AA0262982B82BB6E 

7680 

E3100D8A 
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Columns 

7681- 

8192 

EB3E8F033DA73FA82B3B93E50C60E5936A07D3218946588D0EFB39E1A55 

C0FB9DBA87DA50C4697EE2ED72B004301019E595B92A2F55F7F1B37C203 

0B79057F52 

Row  3585 

Columns 

59CA13359E16B10A7F8778BBAF5D45E32C643B524022FE777A8F557C1414 

4097- 

1D638E84BC4DBB1CE5866CD0B89C1CC5C6F7BF7E25D2B4FC28A16E67C 

4608 

F8BFAC4F4BD 

Columns 

A612F30067700487B6584B1AD578659FC2B7443228B2B7B443882DABBF55 

4609- 

739CB9660F530631A2CFDCBE94D21692CAC01DA9EB5048FFF17BC4FB59 

5120 

57E8C9DF1F 

Columns 

29E0573D85359FB7924AABBDDDCD26F5740FFA6824FCFCBD53BF1DFB5 

5121- 

87E0667641DD3F82962F5E6EA26461279B0F69479645462983DBBBCC544D 

5632 

A90255121EA 

Columns 

A97C7B71923F0382DF60C9E34D84CAC289B578899EBCF924F4304B80581C 

5633- 

9887B1198F074143DCC4324D7DF301466AC97903E688DD2E9186EDD2D90 

6144 

C34202AA3 

Columns 

90815D489B715FF604788F335322DF5C8856FD85F753785A96F4B2561990F4 

6145- 

58C69D3F99A8ED1BE99C3F5A14B19B37AC729B3F35ABF52006E814B5971 

6656 

45FA3FD 

Columns 

86A5A2038BB67CF8225BCCF7A587E0D09B47D26BC4DB017F6A77B6DEC5 

6657- 

AF5B117E399D8A336358D4AABE9C8E7EAAF6447638F2DC66EF65C100D0 

7168 

6EE2020 13042 

Columns 

AD845A43D23E66FBA72D9D56457D66C7E44D98ED1E5F1D063A5D010439 

7169- 

30E9C2EDED8BA9DEE5F9DFF91CD887F097B9A2DF0099E278C253E0A549 

7680 

C7A2D81078C6 

Columns 

680566EA7A1E724A99B5D7099AED278A3065BBC64BED441154DCD346D3 

7681- 

8C9771648D55656B16CF012D0C6EC8F616D3B758089A8147D731AE077D55 

8192 

7204256F93 

D.4.C.  Code  Rate  =2/3,  Information  Block  Size  =  1024,  M  =  256 

The  first  1024  columns  of  G  form  a  1024  x  1024  identity  matrix  and  the  remaining  512 
columns  of  G  form  a  block  matrix  composed  of  16  rows  and  8  columns  of  circulant  matrices, 
each  of  size  64  x  64.  The  first  row  of  each  circulant  is  given  in  hexadecimal  format  in  Table  D-6 
according  to  its  location  in  G.  Subsequent  rows  of  each  circulant  can  be  computed  by  applying 
the  corresponding  number  of  right  circular  shifts  to  the  first  row. 


Table  D-6.  First  Rows  of  Circulants  in  Generator 
Matrix,  r=2/3,  k=1024 

Row  1 

Columns  1025-1088 

51236781781D416A 

Columns  1089-1152 

B0C8419FA21559A8 

Columns  1153-1216 

5F14E1E4D88726F1 

Columns  1217-1280 

762F6ED6CF32F06D 

Columns  1281-1344 

8ABFD971E17A0BE9 

Columns  1345-1408 

A5D147741B698D14 
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Columns  1409-1472 

2A58AB30E2BC32D3 

Columns  1473-1536 

9F251FBC5DB8C768 

Row  65 

Columns  1025-1088 

D73C205BBEB231CB 

Columns  1089-1152 

CAB5EFF5B2C76C71 

Columns  1153-1216 

FA70FAD48828355F 

Columns  1217-1280 

68C6138FA5524A61 

Columns  1281-1344 

BB20031D7AA8FE69 

Columns  1345-1408 

432ADE446F49CE27 

Columns  1409-1472 

5E5DB9CCCEBD1326 

Columns  1473-1536 

E8782B1B01F2ABA2 

Row  129 

Columns  1025-1088 

4748E9513B41147A 

Columns  1089-1152 

17B1FBB78B4F914C 

Columns  1153-1216 

281F5680BA56DE50 

Columns  1217-1280 

74B0FB0817E33E2B 

Columns  1281-1344 

DD166CFB774B5959 

Columns  1345-1408 

AC7FDCEA4FECB5BE 

Columns  1409-1472 

ED747C81B540D66A 

Columns  1473-1536 

B2A6A2039A87967F 

Row  193 

Columns  1025-1088 

4780DCB2DC5CBFAE 

Columns  1089-1152 

55BC8FF84EC89440 

Columns  1153-1216 

E5D411223F09979F 

Columns  1217-1280 

DDDE9D940A15A801 

Columns  1281-1344 

194064639D254969 

Columns  1345-1408 

1BE32DDC829B0032 

Columns  1409-1472 

13265 15A22EE88A2 

Columns  1473-1536 

0EC664DD2D701891 

Row  257 

Columns  1025-1088 

69748DFE6372F2EF 

Columns  1089-1152 

15F3B0D400ACD68A 

Columns  1153-1216 

CF4144CE1FE2581C 

Columns  1217-1280 

79B1A55BA59E54AE 

Columns  1281-1344 

65A2B47EEBAB0CF3 

Columns  1345-1408 

24DD87572CB0F71D 

Columns  1409-1472 

F24ABF15590F4DA6 

Columns  1473-1536 

9C3BAE51969C6502 

Row  321 

Columns  1025-1088 

D3A714B60B22789B 

Columns  1089-1152 

3DF5504D80F54C5A 

Columns  1153-1216 

9D75CF1465031211 

Columns  1217-1280 

09834A0C9F659C99 

Columns  1281-1344 

B9241BDF76EB3788 
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Columns  1345-1408 

6F927251C86DECF1 

Columns  1409-1472 

390BE9F5BBB93D05 

Columns  1473-1536 

C6F435BFA1FF96B6 

Row  385 

Columns  1025-1088 

22246 1B658DC3E91 

Columns  1089-1152 

B01DF2A2EAD2DAA6 

Columns  1153-1216 

5572EE6278F6F63A 

Columns  1217-1280 

17B63CB2FDA3B97F 

Columns  1281-1344 

B233BB259F3D83F7 

Columns  1345-1408 

F64760C774989384 

Columns  1409-1472 

46F57E03F55B1C0B 

Columns  1473-1536 

5AC8A6CEA05466C1 

Row  449 

Columns  1025-1088 

AE8825521F85CA31 

Columns  1089-1152 

37BEED74B5303407 

Columns  1153-1216 

751FC9A15FCEE486 

Columns  1217-1280 

93F0F69BD04E72A4 

Columns  1281-1344 

C0EBFA3F49DF4DBB 

Columns  1345-1408 

03E52D815DC99A1D 

Columns  1409-1472 

98FE8BF01BB2CD6D 

Columns  1473-1536 

009C5290D81A18F6 

Row  513 

Columns  1025-1088 

4FFBAD88545CAA95 

Columns  1089-1152 

0C74659FA4828CA3 

Columns  1153-1216 

60CE56E32DA28B2E 

Columns  1217-1280 

299D4BF82FE54B81 

Columns  1281-1344 

51047BE3B3AE4F4B 

Columns  1345-1408 

F3AC9578B9477A4C 

Columns  1409-1472 

3730F81F92767E11 

Columns  1473-1536 

04E84EC3A3AD1F19 

Row  577 

Columns  1025-1088 

2D0E0CAB8EDD2185 

Columns  1089-1152 

CEFBE8F2F538522A 

Columns  1153-1216 

92DAEDC22C441893 

Columns  1217-1280 

BCB999157B35619D 

Columns  1281-1344 

06995 1BFB90A08E1 

Columns  1345-1408 

54C7E270CBA1656E 

Columns  1409-1472 

7FBBB806B6A06FB3 

Columns  1473-1536 

7224943B1C3A5723 

Row  641 

Columns  1025-1088 

1BAA14752EFCEBC0 

Columns  1089-1152 

CFF0894975557623 

Columns  1153-1216 

FA95908DC3F34D48 

Columns  1217-1280 

FECA650999A26E91 
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Columns  1281-1344 

245433EBBE9CDA13 

Columns  1345-1408 

5771EAEE9B02D8EC 

Columns  1409-1472 

BCEBCA573D3775C8 

Columns  1473-1536 

1E46E2B951D0EAAB 

Row  705 

Columns  1025-1088 

32942E7E4743DDE4 

Columns  1089-1152 

8EA2E60AD62095EE 

Columns  1153-1216 

80E4A736B5E1A3A3 

Columns  1217-1280 

0119062872DAEDE4 

Columns  1281-1344 

E78006958CD99E95 

Columns  1345-1408 

D20625057C99C7A3 

Columns  1409-1472 

B569736DE2167610 

Columns  1473-1536 

0E1C6183ADE09ED0 

Row  769 

Columns  1025-1088 

E5C492DBB48B319A 

Columns  1089-1152 

E2D83ADEEEBBDEEE 

Columns  1153-1216 

AA944EEA53C77DB3 

Columns  1217-1280 

0EAA85D9C13B1E73 

Columns  1281-1344 

8ACED57E3BE4E807 

Columns  1345-1408 

33CB72627624E426 

Columns  1409-1472 

A0C6E669B5C74980 

Columns  1473-1536 

ABBAEEEA2D3B69AA 

Row  833 

Columns  1025-1088 

E8366DDAE56A6DDC 

Columns  1089-1152 

EDED5582E4EA6525 

Columns  1153-1216 

4C9628278ED 17036 

Columns  1217-1280 

6E711B6D20A67966 

Columns  1281-1344 

3B28BDE004C21B93 

Columns  1345-1408 

1BC37B730EEC1786 

Columns  1409-1472 

5D20C81D345EE4B9 

Columns  1473-1536 

1D14A5663D369A93 

Row  897 

Columns  1025-1088 

5EBD4BD39B2217D0 

Columns  1089-1152 

56833BE1CDDBA6BC 

Columns  1153-1216 

B288169B4E3BB726 

Columns  1217-1280 

C2ED28EBEC395D1E 

Columns  1281-1344 

035B30C68E9A6B6E 

Columns  1345-1408 

539836A6E56A7B16 

Columns  1409-1472 

CEB1525C6ADB65A5 

Columns  1473-1536 

5E71754AA458B11A 

Row  961 

Columns  1025-1088 

0DB9D180B21C0B13 

Columns  1089-1152 

417D86C59DE33E49 

Columns  1153-1216 

183A8E6C44DAEA24 
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Columns  1217-1280 

4E224C180C1F0B45 

Columns  1281-1344 

C93CD9CA23658555 

Columns  1345-1408 

7DDEC5E9451AD519 

Columns  1409-1472 

B122C72A6177EE99 

Columns  1473-1536 

1290B4C6B007D973 

D.4.d.  Code  Rate  =2/3,  Information  Block  Size  =  4096,  M  =  1024 

The  first  4096  columns  of  G  form  a  4096  x  4096  identity  matrix  and  the  remaining  2048 
columns  of  G  form  a  block  matrix  composed  of  16  rows  and  8  columns  of  circulant  matrices, 
each  of  size  256  x  256.  The  first  row  of  each  circulant  is  given  in  hexadecimal  format  in  Table 
D-7  according  to  its  location  in  G.  Subsequent  rows  of  each  circulant  can  be  computed  by 
applying  the  corresponding  number  of  right  circular  shifts  to  the  first  row. 


Table  D-7.  First  Rows  of  Circulants  in  Generator  Matrix,  r=2/3,  k=4096 

Row  1 

Columns 

80924E648C014E2C73889C8B87D0491EA9EA060D2902D7ACC8B679CE61 

4097-4352 

EEB5D9 

Columns 

6BB9E90E5C157AA1BE03EE756245D9179063E2CD999EE1E7E7925B3EB7 

4353-4608 

AC7B2D 

Columns 

6CD39516B201E491E2BDCA4E34542B5AE3703B3C8EE753EBE998E87323 

4609-4864 

E0B228 

Columns 

D1E551B2D7E7822E201E24066584D63CAA00E8DB909EB41C4157EBA0E5 

4865-5120 

C76A50 

Columns 

E7C5731746C6DAC260A345189009C0B23372E1E9E0C5A079D00B09158E1 

5121-5376 

64B22 

Columns 

33D5E8A268041CAB66317898CD0024E3106EED5C2171B3E6276B8EA59A 

5377-5632 

A981E0 

Columns 

010BEE3E52A49ED9A6EA7E151ECC72B2AE3BD932065043E7447B4D0EC4 

5633-5888 

A2B93B 

Columns 

E8D345E6D2B0008D1B363BEE296B55AE38E3E16EC5856A122E4931CB3E 

5889-6144 

2424B1 

Row  257 

Columns 

A099B776C642EE1D84B0DB797098E17E75EE9BB5CE7EA87397 1 1 A89660 

4097-4352 

DAE24D 

Columns 

3CA8DE5500E68DB449BEE74251B24E4691EAE386C81014C91AC700298E 

4353-4608 

095E0B 

Columns 

12CEE8B5E6B93C11AD628CB6CB81E76BE095C2C994A8BDDB4E2C48C9 

4609-4864 

42B4D481 

Columns 

1E7E191B30E8EED6D4A7E9BEE81BBB0AE6608E647B1AED9CCA7EEC54 

4865-5120: 

98C03E0E 

Columns 

1132E816BDEA0C3450C3993911E10EB1097CD7A1E32C54C8B009654E56 

5121-5376: 

B25A2D 

Columns 

5ED58EEAED460CEEC18E2EBAD2954467E32118E01D05456DEA2926A1E 

5377-5632: 

761DE76 
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Columns 

4C6C7BF3A2245C1B4630775DC59EA74A14EBCD8B5D72E343BC6F7FEA 

5633-5888: 

452F2CC2 

Columns 

C09CE802B35EBF46D1F3069957DF1D152377F45ADF614CC0F5DAB8FCF 

5889-6144: 

394CCD0 

Row  513 

Columns 

FEFBA8CE169FD3775B2280EF3BD870FDDF7CB95F2943D0EEA84529FF0 

4097-4352 

D1B1C19 

Columns 

0CA5DB06A87541C81BEF913D5145F20EFAD861F673B32028B4713377C0 

4353-4608 

56CE97 

Columns 

CA3F213365EE380F7E90466945BDE9F44087C8C73A7CC5F9DE71B7683D 

4609-4864 

018D86 

Columns 

A6CDFD8D8117748A4B41C3F5A66765495711EDC02F9581F3E7C2E0FD90 

4865-5120 

04B03B 

Columns 

77D0EF5DE2ACACA2A4371A5B111B877D0EDDF83C3341A5AA51261FA 

5121-5376 

4B5A0D7EA 

Columns 

7C563512A6B73B3B43F8D1D113D751D6B2CABBC350FF0F8C29361DCE5 

5377-5632 

EB87C8F 

Columns 

F6DFA5C672C25 1793 137 1ACB6462A596D41419CD4F0F84EFF98DCBBE6 

5633-5888 

10AE03E 

Columns 

05FF840FB320DD5C3FB4FE4A5858510914A5161B2AD3C3E7FD02358505 

5889-6144 

190F0F 

Row  769 

Columns 

5B6D534EDE13068A2459CB07007121B0F07B08B8227047C1A629DCA5A4 

4097-4352 

E30D28 

Columns 

5D00E72E5B6AD57A9F0F9E0608702BDE8BDBFA371C06D96BFE0E60377 

4353-4608 

5A875CB 

Columns 

692EB7DA76BD0D4AFE92FCB5B5184BAA3EEE37900144CA03B7A22EA 

4609-4864 

DE2F061FF 

Columns 

B3CDE2464AF1212979A99380340974A9F85478E5A2E8B907E74EEFA4CB 

4865-5120 

7625E5 

Columns 

41AF736E0AA1416EA676E43CF5DFF372CFFC30D6C0A58A333268136A30 

5121-5376 

20033F 

Columns 

F501 1 1382FEBA594C255896AB59C06638406956F19B67F80A3A7276060D4 

5377-5632 

E7F6 

Columns 

DCB75287BE9A2620A1F594570B269097A51A32548BAA6DD9B429B8AAF 

5633-5888 

992C8C0 

Columns 

6210A36B63DE9C732339DC1AFA94CAB475574A6D1C4D0C17F148B8AD 

5889-6144 

12816B47 

Row  1025 

Columns 

E24D7C17BCC46297EDC41AA9B5C9D93689843027C6A78449F8D151E1F4 

4097-4352 

2BE98F 

Columns 

4544BD9E6975DDD4BC9B3EFAD50AFC582CAE269677B130FED2C39D5E 

4353-4608 

BDEE56B8 

Columns 

6A13BB53C03B0C8A4E0D1697322A1A3055054229A69B6CCB7E1FB0B88 

4609-4864 

5B90CD2 
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Columns 

BE5C66B252E5C51D7D9E9E25922566C18F0234F2A330041AEC6A4F2729 

4865-5120 

A2A30B 

Columns 

1E04A65CF0BA05C62B15FEF9967ECD975EC43C035DE4EE6422237F5683 

5121-5376 

4AC746 

Columns 

4FD0C1AF8A61F56686326F93EF63E2C114D55726A5F74BFD99AE7713DF 

5377-5632 

2DE6CF 

Columns 

A9CC4B50995A682C6F6F12C80929FF208C72007D6A253FD36DE363E8EB 

5633-5888 

F2B614 

Columns 

95F6F59DA4CE4BA4D6D4D37 1 A2484F16EFA33CD34F7 1B8 1702F0E99C0 

5889-6144 

31B089D 

Row  1281 

Columns 

E16A7B75AB838252D1840EF2935AA1CCA5C8470F98202BABA93EEACE 

4097-4352 

43EE56E1 

Columns 

B2D767F35B0F34FCE855B53B6B8DB8DD08BCF47684E904FA47965D7210 

4353-4608 

7897D1 

Columns 

3D38403A0D2696A767679C6F9CC37537A93A125CE7041EC4F39AD74525 

4609-4864 

97ED13 

Columns 

A0CCD841B7CA93DB6F7039B929A820F55A95AA3786C96E0434DA46A08 

4865-5120 

4653B1A 

Columns 

08A907831A27892D0DD5B6C9FCB5229C0C03663794A4E94E3FB22E4068 

5121-5376 

ED0EE8 

Columns 

53BCBD15AA8DEC3451CEF53541B04056E4DCA0393836E9B6DFCF9B01 

5377-5632 

E901D933 

Columns 

BD 1 60 1 66307B70BE56 1 8C6E0B4ADEB  A46F65C69080D4C3FAADF1 AA22 

5633-5888 

911C2C69 

Columns 

42FB1575074655ABD1EFF5784CBE7FA0B110981C8A0BDF01C650189C2D 

5889-6144 

C9FC74 

Row  1537 

Columns 

B4035630 1 IDDE 1 6F92630CF3 1 2B3F7F495E74B3B582DFB940 1F509A35BD 

4097-4352 

2528C 

Columns 

A81600F6437FBD00FCF0E4AD41DE3598434EE3903CD1A17CF618E8E2A4 

4353-4608 

7EBC4C 

Columns 

A1D7816AE33BA46E3A9D5B3CBDACF93D538802ED0FCCEFF193DB9D6 

4609-4864 

B79C7E508 

Columns 

54B42DDFAA7DE9B5299F4C1B5DA05487562D20349282F7061E3159E4EA 

4865-5120 

B09D03 

Columns 

E15D45F2D1694FF3FF1AA1FC1E58E3FBD6875B71B982AD57AC96CD3B7 

5121-5376 

BE8ACC6 

Columns 

90CADDAD41374E4BCA29AAB22CAD61989158C474E0725B4C4C5442D6 

5377-5632 

A12D94D8 

Columns 

2827752CE49CB9C385AD35C1291109892EF85A7A6C043BD8E3BA4AC3D 

5633-5888 

5146FB7 

Columns 

87002794AC4020B7D229EAE70E01E72F1772B0DA401ABE2C2D487EF607 

5889-6144 

24DC83 
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Row  1793 

Columns 

413A0F58974C76AB4C17AB24F37CB1055FC1827A1DDB0456CCAA7F947 

4097-4352 

7CA64FC 

Columns 

904E1D9338D0795C6844F79ED8B26A9D306F66975CE704A925E72EC9550 

4353-4608 

9188B 

Columns 

2B5EC3212ADE35954E1CDA9CB6CCC28E422E23AE81659E6E4AEDD03E 

4609-4864 

EB8AD730 

Columns 

84D1CCA3B5036E031EEDE0E1121E6E62D232DEB74A0582EB3303D1E988 

4865-5120 

10A6C9 

Columns 

221E0EECA2C81259B57E8E6943D0CD36088A64DA7EE2E6E7E0E63EAE87 

5121-5376 

3B8A79 

Columns 

57E9B39245C6173088B024E34ED7B64E8784413EE95E476474EECDAE7BD 

5377-5632 

62E5A 

Columns 

807A807832E6AC83BC7CA7E754BBC7DE72CCC85425068E50ED52419643 

5633-5888 

561832 

Columns 

1B9CE54C055EB01B40740A0D469855292AE8A0C58756BDD3C6DABE268 

5889-6144 

551ED5E 

Row  2049 

Columns 

DD8CE660B7403DC8672EA620E65301B0865A23EE568C173669EE1D7E7A 

4097-4352 

1BD748 

Columns 

3CCEAC84AB188D906D70525D092C3E2B46C6675C1CE4B30AB346022E4 

4353-4608 

3DA20B8 

Columns 

A01DC1159652EA260B411971B0E3D0393C1E75AB0EA462E1D07D0847EE 

4609-4864 

A9CEBA 

Columns 

4153E6B4E4687D434414BAA200EA38CE46B28D3B4055C633AAD0ED2EA 

4865-5120 

CD6B415 

Columns 

5234EA7B72E478A193EC14698C611E3CB70BE72C15E0DCE9CC048A526A 

5121-5376 

C1E46A 

Columns 

969C10820390DE8D90AD0138202A32182398B70405520538D08C1E799EBC 

5377-5632 

0755 

Columns 

53D8304A8B5213EE88DD1620B1A5125AE1CC9A07E95C61C5C6C625E64E 

5633-5888 

ECDBE6 

Columns 

ED1E06EC959EE323ED3E8AE3553D90BD529D699B08B873E164E59B1CD5 

5889-6144 

22AC0E 

Row  2305 

Columns 

A5C8A02849509DECECEADD4C89C03A78E1564A548D89DECD90DDBC 

4097-4352 

AC7964E9E0 

Columns 

545B207877BBAEB5DED6AEAD3967CA72272E128C97B06868ED3BB8599 

4353-4608 

6640432 

Columns 

2995ED49B525D47CE868EED6EDBB0BB6975DC82C8580D00ABCB9EEC6 

4609-4864 

E532A0CB 

Columns 

9E0B1EC3BC16C2E7C94E5149D03677AD039452180B24DA434E5BBAA0B 

4865-5120 

CEE64ED 

Columns 

910009CE6C1 1 178E5BC794754EBA72003E9A53CDA988B33CE2D0A0965D 

5121-5376 

AACA23 
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Columns 

BF8A7AE5330F4813AE7F8E4F25666EAB3F0351BD34ABBFA8874D88D5F 

5377-5632 

C4E9385 

Columns 

45A0C20F7DFD392872ABDCB19E4F6F097044266B9EA6F0B318A5011D0E 

5633-5888 

51E735 

Columns 

EE58F5FC44AE859564B64F3D173C58FAE938AFB934CBB97245F7B1A1D 

5889-6144 

DD4C559 

Row  2561 

Columns 

C7DF1E821B249BE35E6CAB842F3DFCD0141E428141C28BDCF54B09853 

4097-4352 

29F6E2A 

Columns 

D8C083075232BDEADEA797B6C9E15606A72B8B48502B1C044BA89A8D 

4353-4608 

BC54EB6E 

Columns 

718EF66E726EA72E631B9B22E193F012F3FB2D112468B0DB89F0C3C8A14 

4609-4864 

3E9B1 

Columns 

7D6BE8EA6A522A10F46EC5A56E3F572586884547536AFFAD0C82A42D88 

4865-5120 

AAA64B 

Columns 

0B740E17EEF10A800DE1916C291C1535845114313E908D313B58018EB77 

5121-5376 

DED61 

Columns 

9A5F742973 1 308EFAB68D 1725D8F950 1 234F90358694 1 5 A62262095D77  A9 

5377-5632 

613A 

Columns 

9BDCBC26ABDE4672BE5F130E1089BE8BF5CA0ED3FCD9F28B75CC07E9 

5633-5888 

822AA2EF 

Columns 

6AC735D6621C86CEA203E9E1FC993207EDC164396C7C8FF227F92979A3 

5889-6144 

13914D 

Row  2817 

Columns 

8E1D4E308C03F66D73D76A715F859BEDBC8D709D4BEFC1558D74B4986 

4097-4352 

0A90ABA 

Columns 

B67C75041BFB3A61BBBB73DE2B3D7BB5CB254F10257495E3185C71C35 

4353-4608 

59D9CD0 

Columns 

ACB7  A 1 63EB 1E088624F946909B29B2C7373C5CF4F6B 1F3  A75DC49B 1 574 

4609-4864 

B3AAB8 

Columns 

327C55142CE3D1382EA917A7C6730E01BA6BA43767D53E84FFB7D61D6 

4865-5120 

EAD24AD 

Columns 

CFAAC26024A1D642C795400B8646533A435A4FE899704FAFAE2BF452B 

5121-5376 

D9AF093 

Columns 

53759538B5F4A8614F1AB4840CFC1EFD8CAFCB067C991FDF2658ABA23 

5377-5632 

F8B0B93 

Columns 

6B3A35CDECD26C58B9F1318AF46F13767758FC0F74B7DD050A9B1A1C7 

5633-5888 

F98B930 

Columns 

4B4C20D040F3A8C746453ECE10C0A1F4F74BDDB1A8FCFE1DE2C19148 

5889-6144 

A5E88F1C 

Row  3073 

Columns 

A98B4DE68DDB2434893BEF8F2CF8DB584CEE8F0E39D30CD4C87017E7E 

4097-4352 

E6886F8 

Columns 

23024E83F777D7DF0D7E46A8B5F9B1331D0BC2F79BF5559C3241D5BDC7 

4353-4608 

E7A665 
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Columns 

9E1DD50373C16CC97A5E390921B471EF5B39731CCC2CBDD08876080680 

4609-4864 

E9D974 

Columns 

9DE22EE3AB758E85ED490012ECEE20B3329A5648D25859036C0586C65E4 

4865-5120 

6236C 

Columns 

B009BA2650ABAEC45653D61D2BEA255DE767D0B25AC7736E8E5200D21 

5121-5376 

EE3E28E 

Columns 

ED96E63D0A22CD574ED61899ECDEB4BEB333E994AC7791EE89EC600B8 

5377-5632 

57D4DDD 

Columns 

C2773C7DCE36709E70180CEEAE22AD44A4A20211224E8ECEB336A54A68 

5633-5888 

1A1E59 

Columns 

5C00C419C78A79ADA49562EEB784ECE44BAE45C1E75BD84DE7C1C6910 

5889-6144 

0E8B93A 

Row  3329 

Columns 

DAB0C7C65E0D096351BE8A0EE9CEE5E7756A9A47B4EE80420DEEA16B0 

4097-4352 

E74CE18 

Columns 

0EAB86E762595261852E38E9D797D4E796DA18169AEAC99E8235D4DD6C 

4353-4608 

2BB887 

Columns 

15D0E65E9ADB2C67A887E5D8EE4E1080AC968E4C0D673CA7A74759A7E 

4609-4864 

1B4E383 

Columns 

1B5641CE5EADE005EB947BE5E20E7DDAE6372655825B3516E2EC5B36D 

4865-5120 

687895E 

Columns 

2C0BB35E3C3EDA32C19BEE6E3A2397A8E25C646059359D90A1372ECAE 

5121-5376 

E250A43 

Columns 

8AABBE162C4499E2EECEA27E8D7582EB607B88D04E4A6100A3D2E8A88 

5377-5632 

A2E5E80 

Columns 

D9C26C2A023943BC62E3C18658A0E5C64130BEE0D74BBB85EBEEEE197 

5633-5888 

C94C6EC 

Columns 

0AED385393E69EA9E7E69DDC061B85E4E77D0BE2013061E94A0DB8AC2 

5889-6144 

995096E 

Row  3585 

Columns 

775369B59AA940DA96B47429C339536B51ECC59C60BAD762EA275A6A8 

4097-4352 

E90885A 

Columns 

922A84AE2B06B4003C0A7BE22EB211365376C3EBEC03EB0DEA264E6769 

4353-4608 

B57EE2 

Columns 

E5 1 8ED3DD8553DC88 15E57E23DADC 1 A3E99030AA02A3529604EE4BD66 

4609-4864 

D770E8E 

Columns 

8AB3C94077E85772647897A76CEE4EC56ECAA7A28968065CC73BDD88A 

4865-5120 

DA4D60C 

Columns 

9430E05CEEE8ACBBA73038463A9AD3BDE5BA4E94EDA8 1C6C5 1 AB3C6 

5121-5376 

9201906E1 

Columns 

2613EECE235670383ED865C6161C8A8958DC09289EA03658376277BE6E4 

5377-5632 

E62AA 

Columns 

3C90B273B9870A069EE0E5164AA8E837B9905EEE7D3AEB794BA2E4CAA 

5633-5888 

4E1EB01 
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Columns 

5889-6144 

01C2973BD37D564B7D21243A206BD8A7B435428BA8DD3DB7045541BCC 

E000F5F 

Row  3841 

Columns 

CFA89305914BEB1BE84B59A4A18CC1AEB5CC96326ADC69F3B4957198 

4097-4352 

C60BB6E7 

Columns 

DB38C42E2947EFC39D2BBFA07C 1 8C320A22C7B9C6CBFB72E6909BDC 1 

4353-4608 

31B2E15E 

Columns 

ABECA69DD1395554C852ED7EE6817A6152B39B42F6D7D56B781D1803B 

4609-4864 

8307C79 

Columns 

386FFC16B79E309255E7D5933870D116DE3828C68348493D8E288C8A3FB 

4865-5120 

F741F 

Columns 

0936252D32CDEC49ACFE91F2BA885044E0A9ADFEA526F53641F97B8666 

5121-5376 

8C5972 

Columns 

F9D8560A97AFA4282DBCC4250B75A871276434FFA80959F04D3400D819 

5377-5632 

37617D 

Columns 

799C3EDF3F1345908B306D8372A740E96707761FCCA9B861402134AE948 

5633-5888 

8387F 

Columns 

F2DA86FE2BAA7E675DFDED45499AF1B40AE292B1DE6B7A7D4799C3B 

5889-6144 

88177704D 

D.4.e.  Code  Rate  =4/5,  Information  Block  Size  =  1024,  M  =  128 

The  first  1024  columns  of  G  form  a  1024  x  1024  identity  matrix  and  the  remaining  256 
columns  of  G  form  a  block  matrix  composed  of  32  rows  and  8  columns  of  circulant  matrices, 
each  of  size  32  x  32.  The  first  row  of  each  circulant  is  given  in  hexadecimal  format  in  Table  D-8 
according  to  its  location  in  G.  Subsequent  rows  of  each  circulant  can  be  computed  by  applying 
the  corresponding  number  of  right  circular  shifts  to  the  first  row. 


Table  D-8.  First  Rows  of  Circulants  in 
Generator  Matrix,  r=4/5,  k=1024 

^ow  1 

Columns  1025-1056 

678ECB51 

Columns  1057-1088 

FE821D5C 

Columns  1089-1120 

FA5F424B 

Columns  1121-1152 

F55927AA 

Columns  1153-1184 

3E826913 

Columns  1185-1216 

32E04B0C 

Columns  1217-1248 

4F88862B 

Columns  1249-1280 

803432EF 

Row  33 

Columns  1025-1056 

42B27625 

Columns  1057-1088 

9F8DA1E1 

Columns  1089-1120 

F8472D1B 

Columns  1121-1152 

D943D394 

Columns  1153-1184 

29261575 
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Columns  1185-1216 

BA434C68 

Columns  1217-1248 

18EF349A 

Columns  1249-1280 

27CA1CC4 

Row  65 

Columns  1025-1056 

EC900397 

Columns  1057-1088 

64A4A063 

Columns  1089-1120 

9BCEC4A6 

Columns  1121-1152 

D05BA70E 

Columns  1153-1184 

E7155BE1 

Columns  1185-1216 

7EE09CC1 

Columns  1217-1248 

6E2E2059 

Columns  1249-1280 

7E1567E5 

Row  97 

Columns  1025-1056 

5616101C 

Columns  1057-1088 

EA060E2B 

Columns  1089-1120 

B673068B 

Columns  1121-1152 

923BDE8B 

Columns  1153-1184 

B9B9343D 

Columns  1185-1216 

049C63A8 

Columns  1217-1248 

333E9CEE 

Columns  1249-1280 

809B362D 

Row  129 

Columns  1025-1056 

9D41634C 

Columns  1057-1088 

404E17DA 

Columns  1089-1120 

3B4161E2 

Columns  1121-1152 

5235992E 

Columns  1153-1184 

EA4B4B8B 

Columns  1185-1216 

4690BCE1 

Columns  1217-1248 

E9DA36A1 

Columns  1249-1280 

16439BB1 

Row  161 

Columns  1025-1056 

5D7254B5 

Columns  1057-1088 

15B4978B 

Columns  1089-1120 

00D05224 

Columns  1121-1152 

107BD904 

Columns  1153-1184 

C85D7E58 

Columns  1185-1216 

0451E1A5 

Columns  1217-1248 

EE9D1897 

Columns  1249-1280 

913DA6E9 

Row  193 

Columns  1025-1056 

42819E61 

Columns  1057-1088 

343773CA 

Columns  1089-1120 

11A6492A 

Columns  1121-1152 

4832E43E 
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Columns  1153-1184 

849C11ED 

Columns  1185-1216 

F0FE864F 

Columns  1217-1248 

CC270400 

Columns  1249-1280 

9726D66E 

Row  225 

Columns  1025-1056 

89EE2A44 

Columns  1057-1088 

685C1F67 

Columns  1089-1120 

1DF6E416 

Columns  1121-1152 

507BF2EF 

Columns  1153-1184 

8759C2FB 

Columns  1185-1216 

52162ABF 

Columns  1217-1248 

2B61D3FB 

Columns  1249-1280 

988708C4 

Row  257 

Columns  1025-1056 

4A8FEA09 

Columns  1057-1088 

53452354 

Columns  1089-1120 

A33E2E73 

Columns  1121-1152 

271E8211 

Columns  1153-1184 

16DF62E5 

Columns  1185-1216 

03DF81F4 

Columns  1217-1248 

8848BD0F 

Columns  1249-1280 

F95DF357 

Row  289 

Columns  1025-1056 

9BE0A7B3 

Columns  1057-1088 

617256EB 

Columns  1089-1120 

9A4D0BB4 

Columns  1121-1152 

FE3A3A19 

Columns  1153-1184 

FAA63D9E 

Columns  1185-1216 

65328918 

Columns  1217-1248 

D699BA35 

Columns  1249-1280 

4CDE6FE0 

Row  321 

Columns  1025-1056 

848B1FE5 

Columns  1057-1088 

0AB58A6F 

Columns  1089-1120 

341707F1 

Columns  1121-1152 

EF36474B 

Columns  1153-1184 

F623A7A5 

Columns  1185-1216 

A35EC9BA 

Columns  1217-1248 

24909B6E 

Columns  1249-1280 

64A7A898 

Row  353 

Columns  1025-1056 

BDDF3BAE 

Columns  1057-1088 

7202FA26 

Columns  1089-1120 

86F90C57 
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Columns  1121-1152 

A0399F20 

Columns  1153-1184 

972B9A31 

Columns  1185-1216 

87B245AE 

Columns  1217-1248 

E0C5A338 

Columns  1249-1280 

4959AAD9 

Row  385 

Columns  1025-1056 

CE726C27 

Columns  1057-1088 

7B38429A 

Columns  1089-1120 

BA37C244 

Columns  1121-1152 

EE7717DB 

Columns  1153-1184 

E45C99CA 

Columns  1185-1216 

7E3E013B 

Columns  1217-1248 

7B800CA4 

Columns  1249-1280 

6527E2E7 

Row  417 

Columns  1025-1056 

75C63782 

Columns  1057-1088 

1CC40137 

Columns  1089-1120 

51E69E16 

Columns  1121-1152 

414B155E 

Columns  1153-1184 

DE1964DE 

Columns  1185-1216 

E13C71E7 

Columns  1217-1248 

6E9E8044 

Columns  1249-1280 

6C5CEC86 

Row  449 

Columns  1025-1056 

6E2A6DE8 

Columns  1057-1088 

9EE2BE82 

Columns  1089-1120 

D3625355 

Columns  1121-1152 

24466981 

Columns  1153-1184 

D5E14AC1 

Columns  1185-1216 

E1C24AEA 

Columns  1217-1248 

A8850D83 

Columns  1249-1280 

7A3C5120 

Row  48 1 

Columns  1025-1056 

BAABADC3 

Columns  1057-1088 

1ECE066D 

Columns  1089-1120 

76538348 

Columns  1121-1152 

EC5D4D54 

Columns  1153-1184 

43AD46CE 

Columns  1185-1216 

33420 12C 

Columns  1217-1248 

63EBE2DC 

Columns  1249-1280 

D832EE8E 

Row  513 

Columns  1025-1056 

E6EC82E1 

Columns  1057-1088 

4AAEE782 
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Columns  1089-1120 

14D89E38 

Columns  1121-1152 

23C83402 

Columns  1153-1184 

8B48D6BF 

Columns  1185-1216 

C823B89A 

Columns  1217-1248 

68A35626 

Columns  1249-1280 

E89FE121 

Row  545 

Columns  1025-1056 

4BBAA331 

Columns  1057-1088 

20EC16C9 

Columns  1089-1120 

6ADABE06 

Columns  1121-1152 

D803DA6D 

Columns  1153-1184 

ECC89D41 

Columns  1185-1216 

E57B10E8 

Columns  1217-1248 

CC3EE014 

Columns  1249-1280 

4DB74206 

Row  577 

Columns  1025-1056 

503ED586 

Columns  1057-1088 

52E68B91 

Columns  1089-1120 

97D69DE3 

Columns  1121-1152 

129C764E 

Columns  1153-1184 

8B2143E7 

Columns  1185-1216 

A36EE3BA 

Columns  1217-1248 

7C27896C 

Columns  1249-1280 

560E67B5 

Row  609 

Columns  1025-1056 

D70390E6 

Columns  1057-1088 

98B337EA 

Columns  1089-1120 

89568363 

Columns  1121-1152 

2A1681DE 

Columns  1153-1184 

4B4E928C 

Columns  1185-1216 

41EC3D9C 

Columns  1217-1248 

DED92EB2 

Columns  1249-1280 

A5D5C85C 

Row  641 

Columns  1025-1056 

2A5088BD 

Columns  1057-1088 

76CB6810 

Columns  1089-1120 

CB693D21 

Columns  1121-1152 

C0E9EED5 

Columns  1153-1184 

E992506E 

Columns  1185-1216 

299CE082 

Columns  1217-1248 

901155A6 

Columns  1249-1280 

0B93AA16 

Row  673 

Columns  1025-1056 

18EEEECE 
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Columns  1057-1088 

B0063536 

Columns  1089-1120 

95487089 

Columns  1121-1152 

4BB31BB9 

Columns  1153-1184 

66F3FD97 

Columns  1185-1216 

E32B58A0 

Columns  1217-1248 

2A39427A 

Columns  1249-1280 

5CD8DE9F 

Row  705 

Columns  1025-1056 

1A8E8616 

Columns  1057-1088 

C5E7D2B2 

Columns  1089-1120 

5AD2BC4E 

Columns  1121-1152 

BE1E86DB 

Columns  1153-1184 

ACE7BEEA 

Columns  1185-1216 

E3589597 

Columns  1217-1248 

A777654C 

Columns  1249-1280 

12DD1364 

Row  737 

Columns  1025-1056 

EEC03A59 

Columns  1057-1088 

DC450527 

Columns  1089-1120 

33B4C871 

Columns  1121-1152 

BAA2EA33 

Columns  1153-1184 

93A751A6 

Columns  1185-1216 

E9D72E4D 

Columns  1217-1248 

69B50C7E 

Columns  1249-1280 

E74151E9 

Row  769 

Columns  1025-1056 

7BE8519D 

Columns  1057-1088 

AE6EEAEA 

Columns  1089-1120 

268DBA73 

Columns  1121-1152 

A356128C 

Columns  1153-1184 

0418BE2C 

Columns  1185-1216 

1A43465A 

Columns  1217-1248 

60C6DE65 

Columns  1249-1280 

0E2438A0 

Row  801 

Columns  1025-1056 

EC25DC05 

Columns  1057-1088 

66AEE4A8 

Columns  1089-1120 

A72A030A 

Columns  1121-1152 

B11EB610 

Columns  1153-1184 

DD74DAE7 

Columns  1185-1216 

62E6D565 

Columns  1217-1248 

554EAEB7 

Columns  1249-1280 

15E7AE6C 
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Row  833 

Columns  1025-1056 

5147F90A 

Columns  1057-1088 

FFOEECOl 

Columns  1089-1120 

12A9966C 

Columns  1121-1152 

871705B1 

Columns  1153-1184 

E935EE30 

Columns  1185-1216 

46E32957 

Columns  1217-1248 

546D69EC 

Columns  1249-1280 

B8A1BD06 

Row  865 

Columns  1025-1056 

6A80EA6E 

Columns  1057-1088 

71A29506 

Columns  1089-1120 

EE78AACE 

Columns  1121-1152 

8D52B5ED 

Columns  1153-1184 

9E0A4966 

Columns  1185-1216 

61B3B68E 

Columns  1217-1248 

4B17AE96 

Columns  1249-1280 

5B282C2E 

Row  897 

Columns  1025-1056 

75582272 

Columns  1057-1088 

16E54299 

Columns  1089-1120 

7D070B9C 

Columns  1121-1152 

AB130157 

Columns  1153-1184 

76C619D2 

Columns  1185-1216 

5500E2D5 

Columns  1217-1248 

1E980459 

Columns  1249-1280 

5D9C7E83 

Row  929 

Columns  1025-1056 

6A0DDA1D 

Columns  1057-1088 

E6E8B610 

Columns  1089-1120 

25D0E0A1 

Columns  1121-1152 

242749E0 

Columns  1153-1184 

EEDA4A06 

Columns  1185-1216 

072D69D6 

Columns  1217-1248 

03C7DA79 

Columns  1249-1280 

51AA3355 

Row  961 

Columns  1025-1056 

6E9EEEE0 

Columns  1057-1088 

0797CBE1 

Columns  1089-1120 

E936C824 

Columns  1121-1152 

C9C1EAE5 

Columns  1153-1184 

D4607E46 

Columns  1185-1216 

88ED7B0E 

Columns  1217-1248 

92E160AD 

D-33 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  2,  July  2017 


Columns  1249-1280 

731140AD 

Row  993 

Columns  1025-1056 

32FEFCAF 

Columns  1057-1088 

70863B75 

Columns  1089-1120 

3846F110 

Columns  1121-1152 

C4E23DFF 

Columns  1153-1184 

79D3F753 

Columns  1185-1216 

064648FA 

Columns  1217-1248 

830452F5 

Columns  1249-1280 

B9ED8445 

D.4.f.  Code  Rate  =4/5,  Information  Block  Size  =  4096,  M  =  5 12 

The  first  4096  columns  of  G  form  a  4096  x  4096  identity  matrix  and  the  remaining  1024 
columns  of  G  form  a  block  matrix  composed  of  32  rows  and  8  columns  of  circulant  matrices, 
each  of  size  128  x  128.  The  first  row  of  each  circulant  is  given  in  hexadecimal  format  in  Table 
D-9  according  to  its  location  in  G.  Subsequent  rows  of  each  circulant  can  be  computed  by 
applying  the  corresponding  number  of  right  circular  shifts  to  the  first  row. 


Table  D-9.  First  Rows  of  Circulants  in  Generator  Matrix, 

r=4/5,  k=4096 

Row  1 

Columns  4097-4224 

473BC533A12C3596F642673D0DBF1142 

Columns  4225-4352 

079A3868E1A6F556F0DF3DCA4493AE54 

Columns  4353-4480 

AE4C50F12AEF6EEDEA9BB30605F4A24C 

Columns  4481-4608 

B0B2B4B9035331ABF53DE4752E7EDABF 

Columns  4609-4736 

E7E08EF3E22EE7EFE645E9E59507A206 

Columns  4737-4864 

52E4A2C06270B2D1A418134BC0D58678 

Columns  4865-4992 

0A84E53303F4092DB47056AD3C0847AD 

Columns  4993-5120 

2DEF73813B17101E79A3A58A7E91C4E2 

Row  129 

Columns  4097-4224 

667AA815610234DBA0FFA951CABB8BA7 

Columns  4225-4352 

A327 1642E4BCDD24F8D89BD7833 17ABB 

Columns  4353-4480 

CC64FA95F06AE45C7E38935D78BF5F80 

Columns  4481-4608 

5 1 0CE9  ABC6 1 56F008B  3 1 7C79E0 1 22B09 

Columns  4609-4736 

3CB09E20016A5F93E207C144E889F3B9 

Columns  4737-4864 

AE6 1 85E4345C597 1E03  AD499EF850D33 

Columns  4865-4992 

FA8B392CE78B5712290CB2F518F3E0CC 

Columns  4993-5120 

429C39F0915EB60CA0545B6AB2967149 

Row  257 

Columns  4097-4224 

FE9FF6C26898CB926F9BCD129AA52083 

Columns  4225-4352 

3FC159DB58B64D39CB27847434F177E2 

Columns  4353-4480 

E040D7 1 365D96  A 1 D54FD2005 1 D3  A50E7 

Columns  4481-4608 

E8AC736B6D2BB5468FBF68DDF5789C2F 

Columns  4609-4736 

4954E4153CFF0F52F8F8F5B243A03E2B 
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Columns  4737-4864 

99A 1DDD23204D 103E323 1 5  8E0FEE7673 

Columns  4865-4992 

43C2A07046B  A 1 B4307B  A6CEC7D740CEE 

Columns  4993-5120 

CB4E113E94C6CAA4652EED867B43D199 

Row  385 

Columns  4097-4224 

081E779BE01E34C97337A3ABC8698644 

Columns  4225-4352 

9C9E794155E27547283C1AB2706A388D 

Columns  4353-4480 

EB9DED194731EC2AE99EA6B641B309A2 

Columns  4481-4608 

258D45A1BBEAEEC787E61289A54A2473 

Columns  4609-4736 

EDE3E96C7679E979911C4BE65A333250 

Columns  4737-4864 

178259E846AA95577C2EC448EE709423 

Columns  4865-4992 

A6 1BE7CCED0342965C  A234AE029 149 1 6 

Columns  4993-5120 

E045B3C585714E272D40C8085AE5E8E4 

Row  513 

Columns  4097-4224 

7EB352B26E544BDC18D76B323C3CE1BB 

Columns  4225-4352 

8421967EE08A6E719B675E06E13EE05B 

Columns  4353-4480 

672C29DC5B80E18E2E4C42D0E6D5D6D4 

Columns  4481-4608 

7DE072E73A8015862A275B2CEA2EEC1C 

Columns  4609-4736 

284B87ABA22362D98952442BBDEBE4A3 

Columns  4737-4864 

2B798BCD5D8C0B02BBE5DE4A96569E99 

Columns  4865-4992 

409E72E4138595E8B3C14074BD8E33E0 

Columns  4993-5120 

3B07838358BBAE631C8258D6B07D2E1C 

Row  641 

Columns  4097-4224 

403 149A1C88E4D4893EE7 19B2638B7EE 

Columns  4225-4352 

9886E3E90EC0 1 8699E3B39 1 83E22 19DC 

Columns  4353-4480 

E5B0D3  AA45 1 2258679 1 3EE8EE979BBE0 

Columns  4481-4608 

795DECBCC982 10C028ED2 1 380EBDDABE 

Columns  4609-4736 

0BBE0D91EA504DC4DC8848AEA001577E 

Columns  4737-4864 

51653E755E6CB4E75ACE347EC899304D 

Columns  4865-4992 

1D0EE239D8A6C2E2EA13D4CEB3394ECA 

Columns  4993-5120 

BE707E3ACD882B91EDDD44A7EA0D1E3D 

Row  769 

Columns  4097-4224 

14EB386A5A4524983682993353E8D76E 

Columns  4225-4352 

E9850534D2EB4E19E787897435C5EB0E 

Columns  4353-4480 

B680840E8D34A0995BA0A94E309A9194 

Columns  4481-4608 

6C66CAA0567BEED609B6484BCD477702 

Columns  4609-4736 

B62A4053A6916719693D50608EC1D717 

Columns  4737-4864 

23C38E6E64963EE836ADC6BBE39E4CD1 

Columns  4865-4992 

A40947C 1 6  AEAD43E62 1 457BDB766 A 1 57 

Columns  4993-5120 

DD6118ACE503356D0B3479828C296016 

Row  897 

Columns  4097-4224 

AAB1061EC9EA6BA21E81D7E22D3A7ED2 

Columns  4225-4352 

E902B6C336258E5B6B54628AC96116DE 

Columns  4353-4480 

5968E3 167BB 1E2217 14B0E4B3B9D7E0A 

Columns  4481-4608 

E12374361559D0E0E0C7ECC959B1A9D8 
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Columns  4609-4736 

C103B779B3A769AA8D955160E4B9F9B7 

Columns  4737-4864 

231B28E0B7490C8EB883F29AF6CC4F12 

Columns  4865-4992 

A7D1FA32F82AAF128FBC6AC53532AB89 

Columns  4993-5120 

17AC06392CDAC681817D2F5475016296 

Row  1025 

Columns  4097-4224 

434D8612F27169A49ED244393B87DB5E 

Columns  4225-4352 

B66D806A5A9ADF46D83C7DCFDB4B72CA 

Columns  4353-4480 

A78E0C64307885C6E67C870BD21EC431 

Columns  4481-4608 

11B79B0BB0B977D9792535C16AA7D982 

Columns  4609-4736 

B597FD60982B8C42D019390EFA14B3D5 

Columns  4737-4864 

C57FF5CFA1C438AC576782A5B48B78AA 

Columns  4865-4992 

AE278E95DA048F720B7DB5FB6488287B 

Columns  4993-5120 

893C7E7E8DCB6E5ED5DB819D8901B32C 

Row  1153 

Columns  4097-4224 

B7BA8906FC3AEADE22254872ECA99117 

Columns  4225-4352 

74F39404FA2779F4C55D649E5A6AA628 

Columns  4353-4480 

4A1F8910EBF76F2F4E3EF686266CEBB8 

Columns  4481-4608 

8363A57CF1377C68419BEFE6C848FEDA 

Columns  4609-4736 

8F141154BFA88D31446EF367ED965F98 

Columns  4737-4864 

1242B3F840426E98010B84A957090390 

Columns  4865-4992 

9CE9E0B619E61C4A481F1DD44360BCAC 

Columns  4993-5120 

0938AE511B2B47A42F5F59FBF547D991 

Row  1281 

Columns  4097-4224 

85B68FFC07A32A495D9A708FAECD2C41 

Columns  4225-4352 

69CFDFFD21D6B2CF3F91CF5820823B83 

Columns  4353-4480 

7D62406050908C82C2 1CF32B862 1 66F2 

Columns  4481-4608 

82AF2DF8E6CADB5D043FBF863ACE6599 

Columns  4609-4736 

700097EE5FDDD825468C544985C983CE 

Columns  4737-4864 

69EE0178288A8E1A12009EBF2E4382DE 

Columns  4865-4992 

2B8D59DE631991AE1B67C70786B43BE2 

Columns  4993-5120 

860FC3354C9FE4253EBF307D1C643E22 

Row  1409 

Columns  4097-4224 

905330D76B 1 6340 1 20BB399A0806 ICBE 

Columns  4225-4352 

9D5765CE993D7092A8 1 50DE46D6C  A8 10 

Columns  4353-4480 

E03534D4DA2B66A0BF2AEF3B833E18DF 

Columns  4481-4608 

6C 1C0D9EAB 1E26FD248 1F6BB6AB674C6 

Columns  4609-4736 

D98BD8D3FC0E0557352CF52EEA654A92 

Columns  4737-4864 

0DF8D4B0FD41AD3EE547119C2446F840 

Columns  4865-4992 

4C1F458D1E2F4B70D9023F0DFC06EFE9 

Columns  4993-5120 

24349C5D9DE2B048DC74D3E888043526 

Row  1537 

Columns  4097-4224 

E864E5EE002EB3B4C31A8D3B3E22D2C6 

Columns  4225-4352 

B3C4136542237F8E3C75AA228AB1B2F5 

Columns  4353-4480 

43DF20DF407EAC80CAF22FDDADD586C9 
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Columns  4481-4608 

9414219FF80742652531AC5CC0E52866 

Columns  4609-4736 

1A68E6BC5CA7FCA386396D0F56A2E7A3 

Columns  4737-4864 

D9EC25B8DEA08EDB6A9E6CEEEC7B 15C 1 

Columns  4865-4992 

CD48176480B2E0EED349142BE9888043 

Columns  4993-5120 

9A70BAD89B53A4461301DE6C1763EB67 

Row  1665 

Columns  4097-4224 

5C9B0E852875D4B06EEA7EE418710592 

Columns  4225-4352 

6E7C0712083341E6A97E398A275243DC 

Columns  4353-4480 

3D046D9B0B0B6AB3EEB99E72A70BAE35 

Columns  4481-4608 

50E7B484C2530BEE63537B68EBDCE01C 

Columns  4609-4736 

672E8B 1DD95643 1036302E8557CBB4E0 

Columns  4737-4864 

C9CAD206AB0AD88C655E0E52C70AEEA1 

Columns  4865-4992 

EE7EC97E9439C9D4CD71487E10065DE0 

Columns  4993-5120 

532339617D706AEEA50A23B90B57978C 

Row  1793 

Columns  4097-4224 

B7E0C9  A5E3EE66B9  AB  A49 1501 44ECBEE 

Columns  4225-4352 

2C9E63DC 1 8BE8  ADDA0ED7E7E8E7EC5EE 

Columns  4353-4480 

5C55C60E14C3D7AC4D00D9E6C827E1EC 

Columns  4481-4608 

4E40D57E1740089DB1248707D195C038 

Columns  4609-4736 

4500AD976DD32 1E6 13311 3D2447 11330 

Columns  4737-4864 

0260379D0A20D10A899019157631007D 

Columns  4865-4992 

4DE741A808694A9956E493B4668B67ED 

Columns  4993-5120 

E89442CABAA2262C398 17 1D62E938504 

Row  1921 

Columns  4097-4224 

CCE8  A4E 1 3D655D559 1DC40D2C6607CEE 

Columns  4225-4352 

353E539A020B0C608E843A855BA9B7AE 

Columns  4353-4480 

CD31CCCB9388EECDEBEE1CCE42943E77 

Columns  4481-4608 

9CA39E64D8  AC9E23E 1 5  A0CB4C73  ACB80 

Columns  4609-4736 

3BE0E0DA9576923D95089979081ACA77 

Columns  4737-4864 

359B090725B62278E00D0222CAD4C0EE 

Columns  4865-4992 

4ABA29056D55C5AAD990AA10A9A1A9B2 

Columns  4993-5120 

27A09750826682C157BD7CD2178EDC96 

Row  2049 

Columns  4097-4224 

AEC3076AE8AEB82B45EE8E2628E489E1 

Columns  4225-4352 

2CEA95663A96A30EB3831E756D9E666A 

Columns  4353-4480 

011EE24E6C5EE283C3EE09A1D5EAE1B9 

Columns  4481-4608 

7B49CB7B94EDEB207221A9436E1EEDE5 

Columns  4609-4736 

5D36302EEBDD74AD27 1 5 8E4D9DE0EA6E 

Columns  4737-4864 

497015959B333E79885EBE22B9B72707 

Columns  4865-4992 

E330EEAD520B31BAD1A5DC55EE54193A 

Columns  4993-5120 

D6C112E89677E27A26E1DC62E08DE49C 

Row  2177 

Columns  4097-4224 

2DE5B029 1E6 19A 1 8D802502086037C46 

Columns  4225-4352 

730D20AE9364A6AD090B789D8AA6C6CC 
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Columns  4353-4480 

EA476A585503E90BCAAD943DD30E1BCC 

Columns  4481-4608 

1D5C236ED01E9E5C8E94E96EA7252ABE 

Columns  4609-4736 

3EB2DB84EB4837EA5153CA825D11E86B 

Columns  4737-4864 

574E63C92DD0E75AD8DDEE2B37CC97C9 

Columns  4865-4992 

5E83299E60C44293BE0824C62EB7980C 

Columns  4993-5120 

5678B852002834EB2D630EAC536EEB78 

Row  2305 

Columns  4097-4224 

9A41E048C1C68187734BEB916EC3BEAE 

Columns  4225-4352 

4B23BDA1162B30CB7AEA9E03BEBCE597 

Columns  4353-4480 

C65460BEAE9C8913608E9888E738E4A1 

Columns  4481-4608 

017AEE470ECA60E9711E9BE5EB98E7C9 

Columns  4609-4736 

4EE8869A59EDE8BDD52C5B5388B35249 

Columns  4737-4864 

8EB0D25B439273CA6545E82E69D8677C 

Columns  4865-4992 

5B23991A53041EA4B276405C156A9DE5 

Columns  4993-5120 

A90889BC74530A5E87CCE024E591E18E 

Row  2433 

Columns  4097-4224 

22735E1E720A8B3C29A80E3696D6E157 

Columns  4225-4352 

E68ED2E2389D5D2CDC59D706495D815E 

Columns  4353-4480 

D0EE25B73218D5717572387BEA03A7C2 

Columns  4481-4608 

A0717B27763EE223BDA3EB0DAEBEE276 

Columns  4609-4736 

9DBB8235D11298BEE28B39772ED91A35 

Columns  4737-4864 

92DE6EED2E6766E01DBA188153DEA205 

Columns  4865-4992 

48930E9A21873E62863CA15D6DB058D9 

Columns  4993-5120 

61A29088EE3983D0E1699EE0AAEA5ED1 

Row  2561 

Columns  4097-4224 

A73005690098889382252873E627D6EB 

Columns  4225-4352 

7862DE8A3D0E1A9387963E38A82E4703 

Columns  4353-4480 

78BAB9252EE72EB0C798C7C684B6E789 

Columns  4481-4608 

B7480D9712BEA72D122E243674AD887E 

Columns  4609-4736 

EC  1 85 1EB80A37 133B68E0E709DB32E05 

Columns  4737-4864 

A809CB3638414ED6E156821BDAC256E0 

Columns  4865-4992 

B75342B6CEE7ED428521AB48A4C55D66 

Columns  4993-5120 

C9AB047D79A484289C820E8EADD87251 

Row  2689 

Columns  4097-4224 

A69C02525644E41D03197EE26112D606 

Columns  4225-4352 

3DE71AD0410035AE1AE7B0AB310B6967 

Columns  4353-4480 

C4E82E31B4D9B491EE8E4992EDBA61B0 

Columns  4481-4608 

B6B367CDE8DE0CAE22875E641288E733 

Columns  4609-4736 

5C 142A9C7C2E259BD38D66 1 17E9E86 1C 

Columns  4737-4864 

D27BE85E8EEE1920B57D0C62B512E2D6 

Columns  4865-4992 

68B4500340B7B92EDD05  A44D36AC 1 65 1 

Columns  4993-5120 

4E77C4ABE92EE174B5D9E79070685288 

Row  2817 

Columns  4097-4224 

A22B2A6C9A75D7A6EEA5A0DE8A4950E2 
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Columns  4225-4352 

24C4830123FAE1EB6EB0AC9C2D8C508E 

Columns  4353-4480 

1BB99D6785EBCCDD9CD6A50CE53CCA00 

Columns  4481-4608 

0624E36ED0817E2E198340098E60DEBE 

Columns  4609-4736 

A4EB92DD48085594C6E755C563E35020 

Columns  4737-4864 

04BDEE9A2309C6E673CE08D94A45BBC4 

Columns  4865-4992 

8B8EC43906C28869AD4E41EB147A7696 

Columns  4993-5120 

8AB66E9B68EA00BEE90D3E078D0C6EEC 

Row  2945 

Columns  4097-4224 

89A79E9CE0BE90A3D86305B6491A49B9 

Columns  4225-4352 

222A27A68236765AB32D41B1E0616C83 

Columns  4353-4480 

99931668E57EB6378C8E4ED1C27BEDD3 

Columns  4481-4608 

35166846D0C673B9A8D2184C1901433A 

Columns  4609-4736 

4D768A5E0109B5CBC 198869334D8 1C43 

Columns  4737-4864 

2C6A48CC47ED21E9608107EE80EE37AA 

Columns  4865-4992 

4DD3A7395630BE4B64E776C5EC6B2C31 

Columns  4993-5120 

4DC16B1E2B2A7E6E0E9EDAE3B60E8EAA 

Row  3073 

Columns  4097-4224 

CEA794E49EA5A0D88BB31D8ECA7EA8BB 

Columns  4225-4352 

A7AE7EE8A68580E3E922E9E13359B284 

Columns  4353-4480 

91E72AE8E2D6BE7830A1E83B3CDBD463 

Columns  4481-4608 

CE95C0EC1E609370D7E791C870229C1E 

Columns  4609-4736 

71EE3EDE60E2878478934DB285DEC9DC 

Columns  4737-4864 

0E95C103008B6BCDD2DAE85CAE732210 

Columns  4865-4992 

8326EE83C1EBA56EDD15B2DDB31EE7E2 

Columns  4993-5120 

3BA0BB43E83C67BDA1E6AEE46AEE4E62 

Row  3201 

Columns  4097-4224 

565083780CA89ACAA70CCEB4A888AE35 

Columns  4225-4352 

1 2 10EAD0EC9602CC8C96B0A86D3996A3 

Columns  4353-4480 

C0B07EDDA73454C25295E72BD5004E80 

Columns  4481-4608 

ACCE973EC30261C990525AA0CBA006BD 

Columns  4609-4736 

9E079E09A405E7E87AD98429096E2A7E 

Columns  4737-4864 

EB8C9B13B84C06E42843A47689A9C528 

Columns  4865-4992 

DAAA1A175E598DCEDBAD426CA43AD479 

Columns  4993-5120 

1BA78326E75E38EB6ED09A45303A6425 

Row  3329 

Columns  4097-4224 

48E42033B7B9A05149DC839C90291E98 

Columns  4225-4352 

9B2CEBE50A7C2C264EC6E7D674063589 

Columns  4353-4480 

E5B6DEAEBE72106BA9E6676564C17134 

Columns  4481-4608 

6D5954558D23519150AAE88D7008E634 

Columns  4609-4736 

1EA962EBAB864A5E867C9D6CE4E087AA 

Columns  4737-4864 

5D7AA674BA4B1D8CD7AE9186E1D3B23B 

Columns  4865-4992 

047E112791EE97B63EB7B58EE3B94E95 

Columns  4993-5120 

93BE39A6365C66B877AD316965A72E5B 
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Row  3457 

Columns  4097-4224 

1B58F88E49C00DC6B35855BFF228A088 

Columns  4225-4352 

5C8ED47B61EEC66B5004FB6E65CBECF3 

Columns  4353-4480 

77789998FE80925E0237F570E04C5F5B 

Columns  4481-4608 

ED677661EB7FC3825AB5D5D968C0808C 

Columns  4609-4736 

2BDB828B19593F41671B8D0D41DF136C 

Columns  4737-4864 

CB47553C9B3F0EA016CC1554C35E6A7D 

Columns  4865-4992 

97587FEA91D2098E126EA73CC78658A6 

Columns  4993-5120 

ADE 1 97 1 1 208 1 86C  A95C74 1 7  A 1 5690C45 

Row  3585 

Columns  4097-4224 

BE9C169D889339D9654C976A85CFD9F7 

Columns  4225-4352 

47C4 1 48E3B47 1 2D  AA3B  AD  1 AD7 1 873D3  A 

Columns  4353-4480 

1CD630C342C5EBB9 1 83  ADE9BEF294E8E 

Columns  4481-4608 

7014C077A5F96F75BE566C866964D01C 

Columns  4609-4736 

E72AC43A35AD216672EBB3259B77F9BB 

Columns  4737-4864 

18DA8B09194FA1F0E876A080C9D6A39F 

Columns  4865-4992 

809B168A3D88E8E93D995CE5232C2DC2 

Columns  4993-5120 

C7CFA44A363F628A668D46C398CAF96F 

Row  3713 

Columns  4097-4224 

D57DBB24AE27ACA1716F8EA1B8AA1086 

Columns  4225-4352 

7B7796F4A86F1FD54C7576AD01C68953 

Columns  4353-4480 

E75BE799024482368F069658F7AAAFB0 

Columns  4481-4608 

975F3AF795E78D25587 1C7 1B4F4B77F6 

Columns  4609-4736 

65CD9C359BB2A82D5353E007166BDD41 

Columns  4737-4864 

2C54473 14DB027B  lOB  13007 1AD0398D 1 

Columns  4865-4992 

DE 1 9BC7  A6BBCF6  A0FF02 1 AABF 1 2920A5 

Columns  4993-5120 

58BAED484AF89E29D4DBC170CEF1D369 

Row  3841 

Columns  4097-4224 

4C330B2D11E15B5CB3815E09605338A6 

Columns  4225-4352 

75E3D1A3541E0E284F6556D68D3C8A9E 

Columns  4353-4480 

E5BB3B297DB62CD2907F09996967A0F4 

Columns  4481-4608 

FF33AEEE2C8A4A52FCCF5C39D355C39C 

Columns  4609-4736 

5FE5F09ABA6BCCE02A73401E5F87EAC2 

Columns  4737-4864 

D75702F4F57670DFA70B1C002F523EEA 

Columns  4865-4992 

6CE1CE2E05D420CB867EC0166B8E53A9 

Columns  4993-5120 

9DF9801A1C33058DD116A0AE7278BBB9 

Row  3969 

Columns  4097-4224 

4CF0B0C792DD8FDB3ECEAE6F2B7F663D 

Columns  4225-4352 

106A1C296E47C14C1498B045D57DEFB5 

Columns  4353-4480 

968F6D8C790263C353CF307EF90C1F21 

Columns  4481-4608 

66E6B632F6614E58267EF096C37718A3 

Columns  4609-4736 

3D46E5D10E993EB6DF81518F885EDA1B 

Columns  4737-4864 

6FF518FD48BB8E9DDBED4AC0F4F5EB89 

Columns  4865-4992 

BCC64D21A65DB379ABE2E4DC21F109FF 
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Columns  4993-5120 


2EC0CE7B5D40973D 1 3ECE7 1 3B0 1 C6E 1 0 


D.5.  Synchronization 

Current  receiver/demodulator  designs  can  perform  either  coherent  or  non-coherent 
detection  and  demodulation.  To  accomplish  symbol/bit  synchronization,  the  transmitted 
synchronization  sequence  must  contain  sufficient  transitions  to  ensure  symbol/bit  acquisition  and 
tracking.  At  the  same  time,  the  symbol/bit  synchronizer  loop  bandwidth  should  be  designed  for 
optimal  phase-noise  filtering  and  symbol  tracking  performance.  Since  the  use  of  EDPC  code 
does  not  guarantee  sufficient  bit/symbol  transitions  to  acquire  or  maintain  synchronization,  it  is 
highly  recommended  that  a  pseudo-randomizer  be  used  after  EDPC  encoding  in  accordance  with 
Section  D.6. 

The  ASM,  depicted  in  Eigure  D-8  and  Table  D-10,  is  not  randomized.  Randomization 
ensures  that  coded  symbols  are  spectrally  near-white,  thus  allowing  each  ASM  to  provide 
synchronization  for  a  set  of  randomized  codeblocks  in  a  codeblock  frame. 
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Generate 


Codebloctcs 


a 


TSIT" 

D^ect 


■  f  Randomized 

Randomized  output  datastream 

ito  enooderMiodulator)  i  from  demod/deooder) 
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Generator 
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256- bit  ASM 


Pseudo  Random 
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Generator 
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Randomized  Codeblock  (k=4096) 


Eigure  D-8.  ASM/Codeblock  Structure 


Table  D-10.  ASM  Definition 

64-bit  Sequence 

Definition  (hex) 

A 

ECB88938D8D76A4E 

A 

034776C7272895B0 

At  the  transmitter  side,  the  ASM  is  prepended  to  each  set  of  randomized  codeblocks  as 
the  synchronization  header.  At  the  receiver  side,  the  ASM  is  detected  and  located  in  the  received 
data  stream.  Refer  to  Eigure  D-8. 

Eength  of  the  ASM  is  determined  by  the  information  block  length  (k).  Eor  k=1024  the 
ASM  length  will  be  64  bits.  Eor  k=4096  the  ASM  will  be  256  bits.  The  ASM  is  constructed 
with  64-bit  sequences.  The  64-bit  ASM  requires  one  64-bit  sequence;  the  256-bit  ASM 
sequence  requires  four  64-bit  sequences.  Eet  A  be  one  64-bit  sequence  and  A  is  the  inverse  of  A. 
The  structure  of  the  64-bit  sequence  is  A;  the  structure  of  the  256-bit  ASM  is  AAAA.  Table  D-10 
defines  the  two  64-bit  sequences. 
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The  resulting  randomized  codeblock  plus  ASM  is  transmitted  leftmost  bits  first,  making 

the  first  series  of  bits  to  be  transmitted  as  FCB8 . or  111111001011 1000 .  This  is 

true  for  both  64-bit  and  256-bit  ASMs. 

With  the  addition  of  the  ASM  prepended  to  the  codeblock,  over-the-air  channel  rate  is  no 
longer  the  inverse  of  the  code  rate  r.  Table  D-11  shows  the  exact  bandwidth  expansion  factor  for 
each  choice  of  code  rate  and  information  block  length. 


Table  D-11.  Bandwidth  Expansion  Factor 

Information  Block 
Length,  k 

Bandwidth  Expansion  Factor 

Rate  1/2 

Rate  2/3 

Rate  4/5 

1024 

33/16 

25/16 

21/16 

4096 

33/16 

25/16 

21/16 

As  an  example,  assume  an  incoming  baseband  data  rate  of  5  Mbps.  If  an  information 
block  length  of  1024  bits  and  rate  1/2  are  chosen,  the  new  over-the-air  channel  rate  will  be: 

(5  Mbps)*(33/16)  =  10.3125  Mbps 


D.6.  Randomization 

At  the  transmitter/encoder,  a  set  of  codeblocks  in  a  codeblock  frame  shall  be  randomized 
by  exclusive-ORing  the  first  bit  of  the  first  codeblock  with  the  first  bit  of  the  pseudo-random 
sequence  until  the  end  of  the  codeblock.  The  pseudo-randomizer  resets  to  the  initial  state  of  all 
Is  at  the  start  of  each  codeblock  frame  for  each  ASM  period. 

The  pseudo-random  sequence  is  generated  using  the  following  polynomial:  h(x)  =  x8-i- 
x7  -I-  x5  -I-  x3  -I-  1 .  It  has  a  maximal  length  of  255  bits  with  the  first  40  bits  of  the  pseudo-random 

sequence  from  the  generator  as  1111  1111  0100  1000  0000  1110  1 100  0000  1001  1010 .  The 

sequence  begins  at  the  first  bit  of  a  first  codeblock  in  a  codeblock  frame  and  repeats  after  255 
bits,  continuing  repeatedly  until  the  end  of  the  last  codeblock  in  a  codeblock  frame.  The  leftmost 
bit  of  the  pseudo-random  sequence  is  the  first  bit  to  be  exclusive-ORed  with  the  first  bit  of  the 
codeblock.  Figure  D-9  illustrates  the  pseudo-randomizer  block  diagram. 


Figure  D-9.  Codeblock  Randomizer 
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At  the  receiver,  each  original  codeblock  of  a  codeblock  frame  is  reconstructed  using  the 
same  pseudo-random  sequence.  After  locating  the  ASM,  the  pseudo-random  sequence  is 
exclusive-ORed  with  the  received  data  bits  immediately  following  the  ASM.  The  pseudo¬ 
randomizer  resets  to  the  initial  state  of  all  Is  at  the  start  of  each  received  codeblock  frame  for 
each  ASM  period. 

D.7.  Performance 

The  trade  that  must  be  made  when  choosing  the  information  block  size  and  coding  rate  is 
one  between  required  coding  gain,  bandwidth  expansion,  and  fading  channel  characteristics. 
Detection  performance  of  the  code  is  tightly  coupled  to  the  type  of  SOQPSK-TG/FQPSK- 
B/FQPSK-JR  demodulator  used.  Plots  of  simulated  performance  for  all  six  combinations  of 
information  block  size  and  code  rates  with  two  different  types  of  SOQPSK-TG/FQPSK- 
B/FQPSK-JR  demodulators  on  are  shown  in  Figure  D-10  and  Figure  D-11.  Other  demodulator 
configurations  are  considered  in  Perrins.'^’ 


Figure  D-10.  LDPC  Detection  Performance  with  4-state  Trellis 

Demodulator 


E.  Perrins.  “EEC  Systems  for  Aeronautical  Telemetry”.  IEEE  Transactions  on  Aerospace  and  Electronic 
Systems,  vol.  49,  no.  4,  pp.  2340-2352,  October  2013. 
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Figure  D- 1 1 .  LDPC  Detection  Performance  with  Symbol -by-Symbol 

Demodulator 
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APPENDIX  2-E 

Space-Time  Coding  for  Telemetry  Systems 

E.l.  Code  Description 

The  STC  used  in  this  standard  is  based  on  the  Alamouti  STC^*  and  applied  only  to 
SOQPSK-TG  or  any  of  its  fully  interoperable  variants.  The  Alamouti  STC  may  be  described  in 
terms  of  the  OQPSK IRIG-106  symbol-to-phase  mapping  convention  illustrated  in  Figure  E-1. 


c 

1 

• 

(0,  1) 
l-U+iJ 

• 

(1,1)  Boolean 
[+1,  +1 J  analog 

'w  I 

(0,  0) 

l-L-lJ 

• 

^  1 

(LO) 

L+U-lJ 

• 

Figure  E- 1 .  Symbol-to-Phase  Mapping  for  IRIG-106  Offset  QPSK 

Modulation 

The  starting  point  is  the  normalized  analog  values  corresponding  to  each  of  the  OQPSK 
symbols.  Let  [an,  bn]  with  an  =  ±1,  bn  =  ±1  be  the  analog  value  of  the  n-th  symbol.  Suppose  the 
bit  sequence  defines  the  sequence  of  symbols 

[ao,  bo],  [ai,  bi],  [ai,  bi],  [as,  bs],  ...,  [aik,  bik],  [aik+i,  bik+i],  ... 

The  Alamouti  STC  organizes  the  symbols  into  blocks  of  two  symbols,  starting  with  the 
even-indexed  blocks  as  shown.  The  Alamouti  STC  assigns  the  k-th  block  of  symbols 

[aik,  b2k\,  [a2k-¥\,  b2k+\] 

to  antenna  0  and  antenna  1  over  two  consecutive  symbol  times  as  shown  below. 


antenna 

symbol  time  2k 

symbol  time  2k+\ 

0 

[a2k,  b2k] 

[-a2k+\,  b2k+\] 

1 

[a2k+i,  b2k+\] 

[a2k,  ^b2k] 

S.  Alamouti.  “A  Simple  Transmit  Diversity  Technique  for  Wireless  Communications.”  IEEE  Journal  on 
Selected  Areas  in  Communications,  vol.  16,  no.  8,  pp.  1451-1458,  October  1998. 
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Using  the  bit  (Boolean)  assignments  shown  in  Figure  E-1,  the  Alamouti  encoder  can  be 
restated  in  terms  of  the  input  bits  as  follows.  Let  the  sequence  of  input  bits  be 

bo  bi  b2b3\  b^bs  bobi  \  ...  I  b4k  b4k+i  b4k+2  b4k+2  \  ... 

The  STC  encoder  groups  the  bits  into  non-overlapping  blocks  of  four  bits  each  as 
indicated  by  the  vertical  lines.  The  STC  encoder  produces  two  bit  streams  in  parallel:  bo,  which 
is  applied  to  antenna  0,  and  bi,  which  is  applied  to  antenna  1.  The  relationship  between  the  input 
bit  sequence  and  these  two  bit  sequences  is 

h=hhhh\hhhh\  \h  h  h  h  I 
\)=bbbb\bbbb\  \b  b  b  b  I 

where  *^is  the  logical  complement  of  bit  b^. 

An  important  point  here  is  the  notion  of  even-  and  odd-indexed  bits.  The  SOQPSK-TG 
modulator  treats  even-indexed  and  odd-indexed  bits  slightly  differently.  Each  codeblock  must 
begin  with  an  even-indexed  bit. 

An  example  of  encoding  is  as  follows.  Suppose  the  input  bit  sequence  is 

10110100 

The  two  STC  encoded  bit  sequences  are 

b,  =  1  0  0  1  0  1  1  0 

b,  =  1  1  1  1  0  0  0  0 

To  make  provision  for  the  estimation  of  frequency  offset,  differential  timing,  and  the 
channels,  a  block  of  known  bits,  called  pilot  bits,  is  periodically  inserted  into  each  of  the  two  bit 
streams.  A  128-bit  pilot  block  is  inserted  every  3200  Alamouti-encoded  bits.  The  pilot  bits 
inserted  into  the  bo  bit  stream  are  denoted  po  and  the  pilot  bits  inserted  into  the  bi  bit  stream  are 
denoted  pi.  These  pilot  bit  sequences  are 

Po  =  10101000100011011001101011010100 
11011100010000000100100101000111 
11100010100100100000001000111011 
00101011010110011011000100010101 

Pi  =  11100011110001110111011101100001 
11110000011100000011011010111110 
01111101011011000000111000001111 
10000110111011101110001111000111 

A  notional  diagram  illustrating  how  po  and  pi  are  periodically  inserted  into  bo  and  bi, 
respectively,  is  illustrated  in  Figure  E-2.  Note  that  the  bits  comprising  bo  and  bi  may  change 
with  every  occurrence  as  defined  by  the  input  data,  but  the  pilot  bits  po  and  pi  do  not  change 
with  each  occurrence. 
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3200  bits 
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- - »-l< - 

128  bits  3200  bits  128  bits 

Figure  E-2.  Notional  Diagram  Illustrating  the  Periodic  Insertion  of  128 
Pilot  Bits  Every  3200  Alamouti-Encoded  Bits 


E.2.  Modulation 

The  bit  sequences  described  in  the  previous  section  are  modulated  by  a  pair  of  SOQPSK- 
TG  modulators  (or  modulator/transmitters).  The  modulators  should  be  constructed  and  used  as 
follows. 

•  The  modulators  share  a  common  clock.  This  common  clock  is  26/25  times  the  input  clock  to 
accommodate  the  periodic  insertion  of  128  pilot  bits  every  3200  Alamouti-encoded  bits. 

•  The  modulators  should  share  a  common  carrier  reference.  If  this  is  not  possible,  the  two 
carrier  references  should  be  phase-locked  ideally,  or  frequency-locked  at  a  minimum. 

•  Randomization,  if  required,  should  be  applied  before  the  STC  encoder. 

•  Differential  encoding  should  be  disabled.  The  periodically  inserted  pilot  bits  are  to  be  used 
by  the  demodulator  to  estimate  the  magnitudes  and  phases  of  the  antenna-O-to-receiver 
channel  and  the  antenna- 1-to-receiver  channel.  There  is  no  need  to  use  differential  encoding 
because  data- aided  phase  estimates  do  not  possess  a  phase  ambiguity. 

Eigure  E-3  is  a  notional  block  diagram  that  shows  the  relationship  between  the  input  data 
and  clock,  the  bit-level  space-time  encoder,  the  periodic  pilot  bit  insertion,  and  the  SOQPSK-TG 
modulation. 


M.  Rice.  Digital  Communications:  A  Discrete-Time  Approach.  Pearson/Prentice-Hall.  Upper  Saddle  River,  NJ, 
2009. 
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Figure  E-3.  A  Notional  Block  Diagram  of  the  Space-Time  Code 

Transmitter 


E.3.  Resources 

Jensen,  et  al.^°  first  described  the  application  of  space-time  coding  to  the  two-antenna 
problem.  Experimental  flights  confirmed  the  effectiveness  of  the  technique. 


Jensen,  M.,  M.  Rice,  and  A.  Anderson.  “Aeronautical  Telemetry  Using  Multiple-Antenna  Transmitters.”  IEEE 
Transactions  on  Aerospace  and  Electronic  Systems,  vol.  43,  no.  1,  pp.  262-272,  January  2007. 

M.  Rice,  “Space-Time  Coding  for  Aeronautical  Telemetry:  Part  1  -  System  Description,”  in  Proceedings  of  the 
International  Telemetering  Conference,  Las  Vegas,  NV,  October  2011. 

Rice,  M.  and  K.  Temple,  “Space-Time  Coding  for  Aeronautical  Telemetry:  part  II  -  Experimental  Results,”  in 
Proceedings  of  the  International  Telemetering  Conference,  Las  Vegas,  NV,  October  2011. 

K.  Temple.  “Performance  Evaluation  of  Space-Time  coding  on  an  Airborne  Test  Platform.”  Paper  presented  at 
the  50*  International  Telemetering  Conference,  San  Diego,  CA,  October  2014 
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APPENDIX  2-F 

Use  of  Recommendation  ITU-R  M.1459  for  Protection  of  AMT  Ground 
Stations  from  Terrestrial,  Airborne,  and  Satellite  Interference 

F.l.  Introduction  and  Summary 

Since  it  was  approved  for  use  by  the  Radioeommunieation  Sector  of  the  ITU  in  2000,  Rec 
M.1459  has  been  the  international  and  US  standard  for  defining  the  interferenee  proteetion 
criteria  and  the  use  of  those  eriteria  for  AMT  ground  stations. 

Despite  its  title,  Ree  M.1459  pertains  to  interferenee  not  only  from  satellites,  but  also 
from  terrestrial  sources  and  has  been  so  applied  both  domestically  and  internationally.  The 
methodology  presented  in  Annex  A  of  Rec  M.1459  for  computing  band-specific  protection 
levels  also  makes  it  applieable  to  any  frequency  band.  The  proteetion  eriteria  for  lower  L  and 
upper  S  bands  given  in  Ree  M.1459  have  thus  been  extended  to  include  proteetion  criteria  for 
upper  L,  lower  S,  and  lower,  middle,  and  upper  C  bands.  The  protection  criteria  are  included  in 
Chapter  2. 

The  protection  criteria  provided  by  Ree  M.  1459  are  in  the  form  of  PFD  levels  defined  at 
the  aperture  of  the  affeeted  AMT  ground  station  antenna.  Thus,  when  performing  interference 
analysis,  it  is  not  necessary  to  require  information  about  the  specific  technical  parameters  of  the 
affeeted  AMT  ground  station,  sueh  as  the  actual  AMT  receive  antenna  gain,  pointing  direetion, 
noise  figure,  or  system  gain  over  noise  temperature.  The  only  details  needed  are: 

•  the  geographie  loeation  of  the  AMT  ground  station  antenna; 

•  the  height  above  ground  of  the  AMT  ground  station  antenna; 

•  the  mid-band  value  of  the  wavelength  for  the  frequeney  band  under  eonsideration; 

•  an  aceurate  terrain  data  base  in/around  the  AMT  receive  site  (1  arc-second,  or  30  meter 
resolution)  for  use  with  propagation  models  when  eomputing  interferenee  from 
terrestrial  sources; 

•  a  composite  antenna  pattern  based  on  the  methodology  of  Rec  M.  1459,  but  adjusted  for 
the  average  wavelength  of  the  band  under  eonsideration,  to  be  used  when  aggregation 
from  a  large  number  of  terrestrial  sourees  is  being  analyzed. 

Section  R2  contains  several  sample  computations  that  illustrate  how  this  information  is 
used  in  practice.  The  examples  begin  with  simple  eases  involving  a  small  number  of  satellite 
and  terrestrial  interference  sources.  The  scenarios  presented  increase  in  size  and  complexity  to 
include  networks  eomprised  of  thousands  of  interference  sources  (e.g.,  cellular  towers).  A 
variety  of  models,  equations,  and  eomputational  teehniques  is  demonstrated,  underseoring  the 
versatility  and  eomprehensive  applieability  of  the  Ree  M.1459  proteetion  criteria.  A  final 
example  provides  guidance  on  how  to  handle  special  cases,  such  as  when  antennas  larger  than 
those  anticipated  in  Rec  M.1459,  are  used. 

F.2.  Practical  Application  of  the  Rec  M.1459  Protection  Criteria 

The  examples  in  this  seetion  include,  but  are  not  limited  to,  interference  from  satellites, 
terrestrial  microwave  towers,  eellular  base  stations,  portable  medieal  telemetry  deviees,  and 
smartphones.  Both  adjaeent  channel  and  co-channel  interferenee  seenarios  are  ineluded.  Eaeh 
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example  is  intended  to  provide  and  illustrate  one  or  more  building  blocks  that  will  sometimes, 
and  perhaps  often,  be  used  in  end-to-end  interference  analysis. 

The  discussions  and  computations  here  are  based  on  a  combination  of  publicly  available 
data,  standard  assumptions  regarding  typical  values  of  common  parameters,  and  emission  limits 
stipulated  in  FCC  regulations.  In  some  of  the  scenarios,  FCC  regulations  are  used  as  a  source  of 
band-specific  emission  masks  that  define  the  worst-case  limits,  as  a  function  of  frequency,  that 
are  permitted  for  OOBE  from  a  particular  frequency  band  or  set  of  bands.  Thus,  the  examples 
that  follow  are  just  that:  examples.  They  are  intended  to  demonstrate  computational  techniques 
and  analysis.  Unless  otherwise  stated,  they  should  not  be  interpreted  as  either  assertions  or 
policy  statements  regarding  whether  interference  does  or  does  not  exist  in  a  particular  scenario. 

Examples  1-11  address: 

1.  Co-channel  interference  from  a  planned  BSS  satellite  in  geostationary  orbit  into  AMT 
ground  stations  operating  in  the  lower  E-band  between  1435  -  1525  MHz; 

2.  Co-channel  interference  from  multiple  spot-beam  communication  satellites  in 
geostationary  orbit  into  AMT  ground  stations  operating  in  a  portion  of  the  lower  E-band 
from  1518  -  1525  MHz; 

3.  Out-of-band  interference  from  a  SiriusXM  broadcast  satellite  into  an  AMT  ground  station 
in  the  upper  S-band  from  2360  -  2390  MHz; 

4.  Erequency  scaling  of  interference  and  interference  criteria  to  different  reference 
bandwidths; 

5.  Computation  of  path  loss  using  the  two-ray  model; 

6.  Rayleigh  fading  of  the  aircraft  telemetry  signal; 

7.  Computation  of  path  loss  using  commercial  software  that  implements  the  Eongley-Rice 
(E-R)/Irregular  Terrain  Model  (TTM)  and  P.452  models; 

8.  Consideration  of  the  antenna  patterns  of  cellular  base  stations; 

9.  Aggregation  of  interference  from  a  network  of  cellular  base  stations  to  one  or  more  AMT 
ground  stations; 

10.  Considerations  for  the  modeling  of  interfering  systems; 

1 1 .  Coordination  of  AMT  with  4G  Eong-Term  Evolution  (ETE)- A  user  equipment; 

12.  Special  considerations  regarding  AMT  antennas. 

Each  of  these  scenarios  was  chosen  to  illustrate  a  particular  point  or  technique  that  is 
independent  of  Rec  M.  1459,  but  which  is  needed  in  order  for  the  protection  criteria  of  Rec 
M.1459  to  be  properly  applied. 

At  the  outset,  it  should  be  noted  that  the  curvature  of  the  earth  complicates  the 
trigonometry  for  computing  elevation,  azimuth,  and  bearing  angles.  Eor  example,  the  elevation 
angle  computed  for  the  path  from  an  AMT  ground  station  to  a  flight  test  aircraft  320  km  away 
operating  at  an  altitude  of  30,000  feet  will  be  close  to  zero  degrees  due  to  the  curvature  of  the 
earth. 

Using  a  flat-earth  approximation,  the  angle  would  be  computed  to  be  approximately  4 
degrees,  thus  suggesting  incorrectly  that  interference  from  terrestrial  sources  would  not  be 
received  in  the  main  beam  of  the  AMT  ground  station. 
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The  equations  used  in  the  representative  examples  below  assume  a  spherical  earth,  as 
evidenced  by  the  inclusion  of  the  value  for  the  radius  of  the  earth  in  km  (e.g.,  6358  km).  The 
flat-earth  approximation  is  obtained  by  letting  the  value  of  the  earth’s  radius  go  to  infinity. 

Use  of  the  correct  formulas  is  particularly  important  when  computing  the  bearing  angle 
from  a  cellular  tower  to  an  AMT  ground  station  and  when  coding  the  table  look-up  algorithms 
for  choosing  appropriate  cellular  tower  sector  antenna  gain  values  as  functions  of  pointing  angles 
from  the  appropriate  antenna  pattern  files. 

Example  1.  Co-channel  interference  from  a  planned  BSS  satellite  in  geostationary  orbit  into 
AMT  ground  stations  operating  in  the  lower  L-band  between  1435  -  1525  MHz 

Use  of  Rec  M.  1459  begins  with  a  simple  equation, 

pfdrec  Pxmt^xmt  ^  {Pcith_L0SS^  X  —  (F"l) 

where  PFD  is  the  received  PFD  in  watts  per  square  meter.  The  quantity  PxmtGxmt  is  the 
product  of  the  transmit  power  of  the  interfering  source  and  the  gain  of  the  transmit  antenna.  Path 
loss  depends  on  distance,  signal  blockage  due  to  terrain  blockage  and/or  clutter  (e.g.,  buildings), 
and  wavelength  A,.  For  free-space  propagation,  however,  path  loss  is  given  by: 

path  loss  =  (F-2) 

Free-space  propagation  is  appropriate  for  modeling  signals  from  satellites,  such  as  from  a 
geostationary  satellite  to  an  AMT  ground  station  antenna.  This  yields  the  simple  result  that: 

Pfdrec  =  (F-3) 

For  the  sake  of  completeness,  the  received  power,  as  measured  at  the  terminals  of  the 
receive  antenna,  requires  inclusion  of  the  effective  area  of  the  receive  antenna.  This  will  be 
discussed  in  detail  in  example  7.  It  is  sufficient  to  quote  the  result  here: 

Free  =  Pfdrec  X  -4.//  =  (F-4) 

This  is  the  Friis  equation,  where  Aejf  is  the  effective  area  of  the  receive  antenna.  For  a 
parabolic  dish,  Aejf  is  often  approximated  by  0.5  x  TfiP  1'^  ,  where  D  is  the  diameter  of  the  dish. 
The  value  for  the  wavelength  of  the  signal  A,  is  typically  the  mid-band  value  where  F=c/f. 

The  distance  r  and  elevation  angle  a  from  an  AMT  ground  station  antenna  to  a 
geostationary  satellite  are  determined  using  either  standard  textbook  equations  (included  in 
Example  2),  web-based  calculators,  or  from  FCC  filings,  which  can  be  particularly  useful 
because  they  also  include  information  about  the  channel  bandwidths,  signal  power,  and  transmit 
antenna  gain. 

The  elevation  angle  a,  which  does  not  appear  in  equations  F-1  -  F-3,  is  needed  in  order 
to  determine  the  appropriate  protection  criterion  from  Rec  M.1459.  For  example,  the  lower  L- 
band  protection  criteria  from  Table  2-8  present  these  criteria  as  functions  of  a. 

To  apply  this  to  a  particular  case,  a  comparison  of  the  PFD  contours  at  ground  level  of  a 
BSS  satellite  is  compared  with  the  angle-of-arrival  dependent  protection  criteria  of  Rec  M.1459. 
The  contours  were  made  available  by  the  developers  of  the  satellite.  The  comparison  shows 
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conclusively  that  the  planned  deployment  of  the  satellite  would  cause  harmful  interference  to 
AMT  ground  stations  in  the  United  States  (e.g.,  -150  decibels  relative  to  one  watt  [dBw]/m^  in  4 
kHz,  versus  the  allowed  limit  of  -180  dBW/m^  in  4  kHz).  As  a  consequence  of  this  analysis,  the 
satellite  was  not  deployed. 

Specifically,  the  co-channel  emissions  were  so  large  with  respect  to  the  Rec  M.1459 
protection  criteria  that  it  wasn’t  necessary  to  perform  a  detailed,  angle-of-arrival-dependent 
computation  of  the  interference  from  the  satellite. 

Example  2.  Co-channel  interference  from  multiple  spot-beam  communication  satellites  in 

geostationary  orbit  into  AMT  ground  stations  operating  in  a  portion  of  the  lower 
L-band  from  1518  -  1525  MHz 

The  2003  World  Radiocommunication  Conference  coincided  with  the  launch  of  a  new 
generation  of  MSS  geostationary  communication  satellites.  These  satellites,  including  Inmarsat 
IV  and  Thuraya,  introduced  the  use  of  complex  phased-array  beam-forming  networks  with  large 
parabolic  reflectors.  The  resulting  spot  beams  permit  the  following:  the  use  of  portable  handsets 
with  omnidirectional  antennas  for  making  telephone  calls  via  satellite;  and  the  simultaneous 
generation  of  dozens,  and  even  hundreds,  of  simultaneous  beams.  Each  beam  serves  a  separate 
user. 

In  seeking  additional  spectrum  to  support  the  use  of  these  satellites,  the  mobile  satellite 
community  proposed  the  allocation  of  the  AMT  spectrum  from  1518-  1525  MHz  for  co-channel 
sharing  with  the  MSS.  As  with  the  BSS  satellite  in  example  1,  application  of  Rec  M.1459 
demonstrated  that  co-channel  sharing  was  not  feasible. 

In  recognition  of  this,  WRC-2003  modified  Table  21-4  of  Article  21  of  the  International 
Radio  Regulations^"^  to  include  the  following  PFD  fence  that  protects  AMT  operations  in  the 
continental  United  States.  In  other  words,  the  Conference  incorporated  the  protection  criteria  of 
Rec  M.  1459  in  the  international  radio  regulations.  Figure  F- 1  is  an  excerpt  of  Article  21 . 16  of 
these  regulations. 


International  Telecommunications  Union.  “Radio  Regulations:  Articles.”  2012.  Maybe  superseded  by  update. 
Available  at  http://search.itu.int/historv/HistorvDigi talCollectionPocLibrary/l  .41 .48. en.  101  .pdf. 
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21.16  §6  1)  The  power  flux-density  at  the  Earth’s  surface  produced  by  emissions  from  a 

space  station,  including  emissions  from  a  reflecting  satellite,  for  all  conditions  and  for  all  methods 
of  modulation,  shall  not  exceed  the  limit  given  in  Table  21-4.  The  limit  relates  to  the  power  flux- 
density  which  would  be  obtained  under  assumed  free-space  propagation  conditions  and  applies  to 
emissions  by  a  space  station  of  the  service  indicated  where  the  frequency  bands  are  shared  with 
equal  rights  with  the  fixed  or  mobile  service,  unless  otherwise  stated. 


TABLE  21-4  fRcv.WRC-12) 


Frequency  band 

Sers  ice* 

Limit  in  dB(VV/nr)  for  angles 
of  arrival  (6)  above  tbc  horizontal  plane 

Reference 

bandwidth 

0°-5° 

5°-25° 

25°-90° 

1  670-1  700  MHz 

Earth  exploration- 
satellite 

Meteorological-satel  1  ite 

-133 

(value  based  on  sharing  with  meteorological 
aids  service) 

1.5  MHz 

1  518-1  525  MHz 
(Applicable  to  the 
territory  of  the  United 
States  in  Region  2 
between  the  longitudes 
71°  Wand  125°  W) 

Mobile-satellite 
(space-to- Earth) 

()°<6<4° 

4°  <6 
<20° 

20°  <  6 
<60° 

60°  <  6  <  90° 

4  kHz 

-181.0 

-193.0 -t 
20  log  8 

-213.3 -t 
35.6  log  8 

-150.0 

Figure  F-1.  Excerpt  from  Article  21  of  the  International  Radio 

Regulations 


Example  3.  Out-of-band  interference  from  a  SiriusXM  broadcast  satellite  into  an  AMT 
ground  station  in  the  upper  S-band  from  2360  -  2390  MHz 

This  next  example  provides  a  computation  of  OOBE  into  an  AMT  ground  station  from  an 
operational  geostationary  satellite.  This  example  serves  to  show  an  end-to-end  computation  of 
the  out-of-band  signal  received  at  an  AMT  ground  station  antenna  at  Patuxent  River  (Pax  River), 
Maryland  from  the  SiriusXM  satellite  denoted  as  FM-6.  This  is  a  Satellite  Digital  Audio  Radio 
Service  (SDARS)  broadcast  satellite  in  geostationary  orbit  above  the  equator  at  1 15.2  degrees 
west  longitude.  FM-6  broadcasts  in  a  4.1-MHz  portion  of  the  2320.0  -  2332.5  MHz  band. 

Note  that  the  SDARS  band  (2320-2345  MHz)  is  separated  from  the  2360  -  2390  MHz 
AMT  band  by  the  2345  -  2360  MHz  WCS  band  (which  is  the  topic  of  example  6,  below). 

Given  that  the  SDARS  channel  is  more  than  15  MHz  away  from  the  edge  of  the  AMT 
band  at  2360  MHz,  co-channel  sharing  is  not  relevant;  however,  the  OOBE  of  the  FM-6  satellite 
remain  a  concern,  due  to  the  high  gain  (30  -  40  decibels  isotropic  [dBi]  and  more)  of  a  typical 
AMT  ground  station  antenna. 

The  FCC  restricts  the  OOBE  of  EM-6,  relative  to  its  mean  transmitter  power  level  Pxmt 
(and  not  including  the  effects  of  the  satellite’s  antenna  gain  Gxmt)  in  the  ECC  Rules,  part 
§25. 202(f)  (1),  (2),  and  (3).^®  These  are  available  online,  but  are  restated  here: 


The  satellite  is  actually  in  operation  at  1 16. 1°  W,  but  the  computations  here  are  performed  for  its  originally 
intended  geostationary  orbital  slot. 

Code  of  Federal  Regulations,  Frequencies,  frequency  tolerance,  and  emission  limits,  title  47,  sec.  25.202. 
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The  mean  power  of  emissions  shall  be  attenuated  below  the  mean  output  power 
of  the  transmitter  in  accordance  with  the  following  schedule: 

(1)  In  any  4  kHz  band,  the  center  frequency  of  which  is  removed  from  the 
assigned  frequency  by  more  than  50  percent  up  to  and  including  100 
percent  of  the  authorized  bandwidth:  25  dB; 

(2)  In  any  4  kHz  band,  the  center  frequency  of  which  is  removed  from  the 
assigned  frequency  by  more  than  100  percent  up  to  and  including  250 
percent  of  the  authorized  bandwidth:  35  dB; 

(3)  In  any  4  kHz  band,  the  center  frequency  of  which  is  removed  from  the 
assigned  frequency  by  more  than  250  percent  of  the  authorized 
bandwidth:  An  amount  equal  to  43  dB  plus  10  times  the  logarithm  (to 
the  base  10)  of  the  transmitter  power  in  watts. 

Since  the  authorized  bandwidth  of  FM-6  is  4. 1  MHz  and  the  AMT  band  is  removed  from 
this  frequency  by  more  than  250%,  the  43  +  10  log  (P)  rule  applies,  where  P  is  the  out-of-band 
transmitter  PSD  in  watts  per  4  kHz  of  bandwidth.  Specifically,  the  value  43  +  10  log(P)  is  the 
amount  the  OOBE  must  be  attenuated  with  respect  to  the  transmitter  power  P  per  4  kHz  of 
bandwidth.  With  the  rule  written  in  this  manner,  if  the  transmitter  power  P  is  increased,  the 
amount  by  which  the  OOBE  must  be  attenuated  increases  by  the  same  amount. 

(This  is  a  well-recognized  OOBE  standard,  but  it  is  essential  to  note  that  the  reference 
bandwidth  for  the  example  here  is  stipulated  to  be  4  kHz,  whereas  a  reference  value  of  1  MHz 
may  be  more  common  in  ECC  rules). 

The  purpose  of  the  log(P)  term  is  to  set  a  hard  OOBE  power  limit  that  is  independent  of 
the  mean  in-band  transmitter  power  P.  Eor  the  purpose  of  computing  interference  into  AMT 
operations  in  2360  -  2390  MHz  using  equations  E-l-E-3,  the  interference  from  EM-6  can  be 
characterized  simply  by  setting  the  transmitter  power  P  to  0  dBW.  Then,  the  magnitude  of  the 
interfering  level  Pxmt  is  -43  dBW,  which  is  equal  to  -13  dBm,  or  50  pW  per  4  kHz.  This 
corresponds  to  an  attenuation  of  the  in-band  power  by  43  dB.  Note  that  if  the  in-band  power  is 
set  to  10  dBW,  the  43  +  10  log(P)  rule  requires  53  dB  of  out-of-band  attenuation,  and  the  value 
of  Pxmt  is  unchanged. 

With  respect  to  equations  E-1  -  E-3,  to  compute  the  interference  from  EM-6  into  any 
AMT  ground  station,  it  is  also  necessary  to  know  the  following. 

•  The  satellite’s  transmit  antenna  gain  Gxmt  in  the  direction  of  the  affected  AMT  site  (in  order 
to  convert  the  43  +  10  log(P)  value  into  a  radiated  power  level).  This  satellite-specific 
information  is  usually  derived  from  information  provided  by  the  satellite  operator  or  from 
ECC  and/or  TTU  technical  filings.  Eor  this  example,  the  information  is  obtained  from  an 
ECC  filing,  as  shown  later  in  this  section. 

•  The  angle  of  arrival  of  the  signal  at  the  AMT  site  (in  order  to  determine  the  appropriate 
value  of  the  protection  criteria).  This  can  be  obtained  from  a  graph  in  the  same  ECC  filing 
or  can  be  computed  from  equations  E-5a  and  E-5b. 

•  The  distance  from  the  satellite  to  the  ground  station  (in  order  to  compute  the  free  space  path 
loss).  This  is  computed  from  equation  E-6. 
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Note  that  these  equations,  as  written,  apply  only  to  geostationary  satellites.^’ 


Us  =  arcsin[cos(9g)cos((psg)]  (F-5a) 


a  —  arctan 


satellite  i 


cos(a5) 


(F-5b) 


7"  ^ ^satellite  ^earth  COS^(cr)  RgQ^^iiSiTl(cc)  (F  5c) 

where  a  is  the  elevation  angle  to  the  satellite  (which  is  the  same  as  the  angle  of  arrival  a 
of  the  interference  from  the  satellite),  0e  is  the  latitude  of  the  AMT  ground  station,  (|)ie  is  the 
difference  in  the  longitude  values  of  the  earth  station  and  the  satellite,  and  r  is  the  distance  from 
the  AMT  ground  station  to  the  satellite.  Note  that  for  geostationary  satellites,  the  orbital  radius 
Rsateiiite  is  the  radius  of  the  earth,  6358  km,  added  to  the  height  of  the  satellite  above  the  surface 
of  the  earth,  36,000  km.  For  an  angle  of  arrival  of  a  =  90°,  equation  F-5  yields  the  value  of  r  = 

(Rsateiiite  Rearth)- 

The  geometry  described  by  these  equations  in  shown  in  Figure  F-2,  excerpted  from  the 
text  by  Richharia.^^  The  angle  q  in  the  figure  corresponds  to  the  angle  a  in  equations  F-5  and  F-6. 
The  elevation  cut  is  a  two-dimensional  surface  for  which  the  trigonometry  of  the  earth’s 
curvature  can  be  solved  by  inspection.  For  the  sake  of  completeness,  the  geometry  used  for 
computing  the  azimuth  angle  is  also  shown.  Although  computation  of  the  azimuth  angle  is  not 
required  here,  it  is  needed  for,  and  discussed  in,  example  8. 


This  is  because  the  declination  of  the  satellite  is  set  to  0  degrees,  which  causes  several  of  the  terms  from  a  more 
general  set  of  equations  to  disappear. 

M.  Richharia.  Satellite  Communications  Systems,  Second  Edition,  New  York;  London;  McGraw-Hill,  1999,  page 


37. 
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Figure  F-2.  Geometry  of  a  Geostationary  Link  Showing  (a)  Elevation, 

(b)  Azimuth  from  a  Point  T  on  the  Earth. 

Eor  Pax  River,  the  latitude/longitude  is  approximately  38°N/76°W.  Assuming  an  earth 
radius  of  6358  km,  a  satellite  orbital  radius  of  6358  km  -i-  36,000  km,  a  satellite  sub-orbital 
longitude  (also  known  as  Right  Ascension)  of  1 15.2°W,  an  OOBE  of  -43  dBW/4kFlz,  and  the 
maximum  value  of  the  FM-6  antenna  gain  of  34.7  dBi  (from  Eigure  E-3)  yields: 

Ug  =  arcsin[cos(38‘^cos(llS.2°—  76^]  =  37.64°  (E-6a) 

a  =  arctan  -  /42358km)  _  30.18°  (E-6b) 

(  cos(as)  ) 

r  =  V423582/cm2  -  63582  /cm^cos^ (30.18  °)  -  6358  km  sm(30.18  °)  =  38804  km  (E-6c) 

Contours  shown  in  Eigure  E-3  are  -2,  -4,  -6,  -8,  -10,  -15,  and  -20  dB  relative  to  the 
beam  peak  of  34.7  dBi. 
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Figure  F-3.  Digital  Audio  Radio  Service  Downlink  Beam  Gain  Contours 

Thus,  the  elevation  angle  a  =  30.2°  and  the  distance  r  from  the  ground  station  to  the 
satellite  is  38,804  km.  Using  the  Friis  equation,  we  have  a  received  PFD  at  the  ground  station 
PFDrec  of 


PtGt  _ 

47rr2  ~  471(38804X103)2 


-171^^^/  2  in  4  kHz 


(F-7) 


The  upper  S-band  protection  criteria  provide  three  PFD  protection  values  as  a  function  of 
a,  as  shown  in  Table  2-8. 

Thus,  the  relevant  Rec  M.1459  protection  criterion  for  this  example  is  the  value  for  an 
interference  angle  of  arrival  >1 1.5°,  which  is  -162  dBW/m^  in  4  kHz. 

Since  the  OOBE  fall  below  the  maximum  level  stipulated  by  Rec  M.1459  for  this  angle 
of  arrival,  there  is  no  out-of-band  interference  from  FM-6  to  the  AMT  site  at  Pax  River.  Note 
that  the  derivation  of  this  result  required  no  information  about  the  size,  tower  height,  or  pointing 
direction  of  the  AMT  antenna. 

Repeating  the  computation  for  other  ground  stations  is  straightforward;  however,  since  no 
analytic  expression  for  the  antenna  gain  of  the  satellite  is  available,  the  appropriate  value  of  the 
gain  of  the  satellite’s  downlink  antenna  must  be  obtained  from  Figure  F-3.  Figure  F-4,  which 
shows  the  angle  of  arrival  of  the  signal  from  the  satellite,  provides  a  convenient  check  of  the 
computation  of  a  from  equations  F-5a  and  F-5b. 
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Figure  F-4.  Elevation  Angles  from  Surface  of  the  Earth  to  the  1 15.2° 
West  Eongitude  Orbital  Eocation 


Example  4.  Erequency  scaling  of  interference  and  interference  criteria  to  different 

reference  bandwidths 

As  mentioned  above,  the  reference  bandwidth  of  4  kHz  for  the  FED  protection  levels  in 
Rec  M.1459  is  easily  scaled  to  other  values.  This  is  done  assuming  that  the  required  protection 
level  is  independent,  of  which  4  kHz  of  a  typically  1-5  MHz  AMT  channel  is  affected. 

This  example  must  also  take  into  account  the  reference  bandwidths.  Eor  example,  the 
permitted  interference  into  a  1-MHz  AMT  channel  is  10^4000  times  the  appropriate  dB(W/m^) 
in  4  kHz  protection  level  from  the  list  above;  however,  the  spectral  density  of  the  interference 
into,  for  example,  a  5 -MHz  AMT  channel  at  1520  -  1525  MHz,  may  vary  across  the  5  MHz  in 
question.  In  addition,  the  reference  bandwidth  specified  for  the  protection  criterion  for  a  given 
frequency  band  may  be  as  large  as  27  MHz,  which  is  the  case  for  the  EESS  band  from  1400  - 
1427  MHz;  however,  the  interference  into  the  AMT  band  may  be  a  function  of  frequency.  This 
is  the  case  for  interference  from  the  WCS  service  in  2345  -  2360  MHz  (i.e.,  the  band  that 
separates  SiriusXM  from  the  AMT  frequencies  in  the  upper  S-band  from  2360  -  2395  MHz). 

In  Section  27.53  of  its  rules  (cf.  footnote  392  of  the  ECC’s  Order  on  Reconsideration)^^, 
the  ECC  stipulates  that  interference  into  the  AMT  band  at  2360  -  2390  MHz  from  the  WCS  band 
at  2345  -  2360  MHz  is  to  decrease  as  a  function  of  frequency  according  to  the  following 
emission  mask: 

Specifically,  WCS  base  and  fixed  stations’  OOBE  must  be  attenuated  by  a  factor 
of  not  less  than  43  -i-  10  log  (P)  dB  in  the  2360-2362.5  MHz  band,  55  -i-  10  log  (P) 
dB  at  2362.5-2365  MHz  band,  70  -i-  10  log  (P)  dB  at  2365-2367.5  MHz  band,  72 


Federal  Communications  Commission.  “Amendment  of  Part  27  of  the  Commission’s  Rules  to  Govern  the 
Operations  of  Wireless  Communications  Services  in  the  2.3  GHz  Band.”  WT  Docket  No.  07-293.  In  Order  on 
Reconsideration.  FCC  12-130.  17  October  2012.  Available  at  https://apps.fcc.gov/edocs  public/attachmatch/FCC- 
12-130Al.pdf. 
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-I-  10  log  (P)  dB  at  2367.5-2370  MHz  band,  and  75  -i-  10  log  (P)  dB  above  2370 
MHz.  WCS  mobile  and  portable  devices’  OOBE  must  be  attenuated  by  a  factor 
of  not  less  than  43  -i- 10  log  (P)  dB  at  2360-2365  MHz,  and  70  -i- 10  log  (P)  dB 
above  2365  MHz.  See  2010  WCS  R&O,  25  FCC  Red  at  11766  para.  135,  11785 
para.  182;  47  C.F.R.  §§  27.53(a)(l)(iii)  and  (4)(iii). 


Figure  F-5  shows  the  FCC-specified  emissions  profile  in  graphical  form.  The  vertical 
axis  represents  xx  +  10  log(P)  in  dB. 


2390  MHz 

The  rule  above  provides  the  guidance  on  how  to  compute  the  net  interference  from  a 
WCS  transmitter  into  a  5-MHz  AMT  band,  for  example,  operating  at  2360  -  2365  MHz.  The 
two  OOBE  levels,  -43  dBW  and  -55  dBW  are  averaged  according  to  the  following  equation: 

OOBE  in  Watts  per  4  kHz  averaged  across  5  MHz  at  (2360  —  2365  MHz) 

=  X X  {(2.5/j)  X  10-«  +  (2.5/^)  X  10-] 

To  convert  from  watts  to  dBW,  the  result  of  equation  F-8  is  converted  to  a  base  ten 
logarithm  and  multiplied  by  10,  as  usual. 

Note  that  Gwcsxmt  is  the  gain  of  the  WCS  transmit  antenna  in  the  direction  of  the  AMT 
ground  station  antenna  that  is  being  considered.  In  equation  F-8,  the  4E3/5E6  term  re¬ 
normalizes  the  average  OOBE  level  across  the  5-MHz-wide  AMT  channel  width  to  the  4-kHz 
reference  bandwidth  of  Rec  M.  1459. 
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Equation  F-8  is  the  EIRE  of  the  interfering  WCS  transmitter  as  measured  at  the  aperture 
of  the  WCS  transmit  antenna.  To  compute  the  interference  received  at  the  aperture  of  the  AMT 
ground  station  antenna,  it  is  necessary  to  include  the  path  loss  by  using  equation  F-1.  It  is 
necessary  when  using  equation  F-1  to  convert  the  path  loss  to  dB  or  the  EIRP  from  dBW  to  watts 
when  using  equation  F-1.  For  comparison  with  the  protection  levels  of  Rec  M.1459,  the  result  of 
equation  F-1  should  be  converted  to  dBW/m^  in  4  kHz. 

It  is  important  to  note  that  the  OOBE  levels  given  above  represent  a  “stair-step  pattern”, 
where  the  OOBE  in  each  segment  of  spectrum  (in  this  case,  each  2.5-MHz  segment)  is  constant. 
Actual  OOBE  measurements,  which  are  typically  used  for  computations  when  available, 
decrease  from  one  end  of  the  band  segment  to  the  other.  In  order  to  average  the  OOBE  properly 
in  these  conditions,  the  2.5-MHz  segments  are  broken  up  into,  for  example,  0.1  to  1.0-MHz 
segments.  These  are  then  averaged  using  the  methodology  of  equation  F-8,  but  with  more  terms 
inside  the  curly  brackets.  To  determine  whether  the  segments  are  narrow  enough,  it  is  sufficient 
to  keep  dividing  the  segments  by  a  factor  of  2  and  then  re-computing  the  OOBE  using  equation 
F-8.  This  is  repeated  until  the  end  result  is  constant  within  the  desired  resolution  of  the 
computation  (e.g.,  0.1  dB). 

Figure  F-6  illustrates  the  difference  between  the  stair-step  emissions  masks  published  by 
the  FCC  and  by  an  industry  group,  in  this  case  the  Third  Generation  Partnership  Project,  or  3GPP 
consortium.  Figure  F-6  also  shows  the  simulated  in-band  and  OOBE  of  a  4G  FTE-A  handset 
uplink  as  a  function  of  the  number  of  resource  blocks  assigned  to  a  particular  signal. 
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It  is  useful  to  work  the  problem  of  OOBE  from  aireraft  AMT  transmitters  into  the  EESS 
spectrum  from  1400  -  1427  MHz.  Resolution  750®'  stipulates  that  the  net  radiated  OOBE  from 
an  AMT  transmitter  operating  in  the  band  1429  -  1452  MHz  (not  including  the  gain  of  its 
antenna),  when  averaged  over  the  entire  27 -MHz  EESS  band,®^  should  not  exceed  a  power  level 
of -28  dBW. 

Chapter  2  stipulates  that  the  OOBE  in  any  1  MHz  from  an  AMT  transmitter  be  attenuated 
by  an  amount  of  at  least  55  -i-  10  log(P)  dBW.  When  scaled  to  a  bandwidth  of  27  MHz,  an 
additional  10  log(27  MHz/1  MHz)  =  14.3  dB  must  be  added  to  the  -55  dBW  OOBE  level.  This 
yields  an  OOBE  of  -41  dBW  per  27  MHz,  which  is  well  below  the  requirement  of  Resolution 
750. 


The  point  here  is  that  when  scaling  from  one  reference  bandwidth  to  another,  at  least 
some  insight  into  the  context  of  the  problem  is  needed.  Simply  applying  the  same  rule,  by  rote, 
from  one  scenario  to  another  can  lead  to  errors. 


“  Wireless  Communications  Association.  “4G  Device  Out  of  Band  Emissions  and  Larger  Channel  Bandwidths,” 
October  2011.  Accessed  21  March  2017.  Available  at  httpsV/ecfsapi.fcc. gov/file/702 17 15550.pdf. 

International  Telecommunications  Union.  “Compatibility  between  the  Earth  exploration-satellite  service 
(passive)  and  relevant  active  services”  Final  Acts  WRC-15  -  World  Radiocommunication  Conference.  Geneva, 
2015.  pp.  399-403. 

The  wideband  radiometric  sensors  aboard  EESS  satellites  apparently  receive  signals  across  the  entire  27  MHz  of 
the  band  at  once,  with  no  effort  made  to  determine  where  in  the  band  a  signal  originates. 
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Example  5:  Computation  of  path  loss  using  the  two-ray  model 

For  computing  interference  to  an  AMT  ground  station  from  terrestrial  sources,  it  is 
necessary  to  include  the  effects  of  terrain,  the  curvature  of  the  earth,  ground  reflections,  Fresnel 
zone  impingement,  etc.  All  of  these  effects  can  be  lumped  into  the  value  of  path  loss  that  is 
defined  by  equation  F-2. 

With  the  exception  of  what  is  known  as  the  two-ray  model,  consideration  of  these  effects 
in  a  path  loss  computation  requires,  in  addition  to  antenna  height  information  and  the  distance 
between  the  interferer  and  victim  receiver,  an  accurate  terrain  database  (i.e.,  a  topographical  map 
of  the  path  between  the  interference  source  and  the  AMT  site).  Other  effects,  such  as  additional 
path  loss  caused  by  buildings  and  other  clutter,  can  be  included  as  long  as  the  details  of  such  loss 
are  justified  by  measurements  and  databases  whose  accuracy  and  precision  go  well  beyond  the  1 
arc-second  (30  meter)  resolution  that  is  typically  used  for  path  loss  modeling  at  this  time. 

The  two-ray  model  treats  the  ground  as  a  reflector,  and  takes  into  account  the  interference 
nulls  caused  by  this  reflection  that  occur  at  various  distances  and  heights  from  the  transmitting 
aircraft  or  interference  source.  Figure  F-7  shows  this  graphically.  When  a  resulting  null 
coincides  in  position  with  the  aperture  of  the  AMT  receive  antenna,  a  significant  signal  fade  (15 
-  30  dB)  occurs.  Depending  on  the  bandwidth  of  the  signal,  the  fade  can  cause  attenuation 
across  the  entire  bandwidth  of  the  signal,  or  can  cause  just  a  portion  of  the  signal  bandwidth  to 
suffer  a  reduction  in  received  signal  power. 


Reflection  can  also  cause  enhancement  of  the  received  signal  (or  interference);  however, 
for  a  two-ray,  as  opposed  to  three-or-more-ray  model,  this  enhancement  cannot  exceed  3  dB.  As 
noted,  the  fades  can  always  be  considerably  larger  than  3  dB  in  their  amplitude.  In  fact,  for 
aircraft,  fades  can  occur  not  only  from  ground  reflection  of  the  telemetry  signal,  but  from 
unwanted  reflections  of  the  telemetry  signal  from  aircraft  structures  or  from  blockage  of  the 
direct  signal  path  from  the  aircraft  antenna  to  the  ground  station  during  aircraft  maneuvers. 

Since  an  aircraft  in  flight  is  constantly  moving,  telemetry  signal  fades  are  strong 
functions  of  time.  For  modeling  purposes,  this  time  dependence  is  characterized  by  a  change  in 
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the  availability  of  the  telemetry  link.  This  is  a  key  feature  of  Rec  M.  1459,  and  is  the  subject  of 
example  6. 

For  static  interferers,  such  as  interference  from  a  cellular  tower,  fades  can  be  regarded  as 
being  constant,  and  are  accounted  for  in  the  path  loss  software. 

A  graphical  representation  of  path  loss  versus  distance  of  the  two-ray  model  is  shown  in 
Figure  F-8.^^  Note  that  the  fades  are  deep  and  the  signal  enhancements  are  shallow.  It  is 
important  to  understand  that  the  graph  is  for  a  particular  combination  of  tower  heights  and  signal 
wavelength. 


Figure  F-8.  Comparison  of  Free-Space  One-Slope  and  Two-Ray 

Propagation  Models 

Fades  are  most  prominent  near  the  transmitter.  For  example,  the  two-ray  model  is 
evident  on  airport  aprons  when  a  telemetry  test  cart  is  used  to  receive  TM  signals  from  an 
aircraft  parked  several  hundred  feet  away.  More  importantly,  the  long-range  reduction  in  signal 
strength  for  the  two-ray  model  falls  faster  than  the  1/r^  (i.e.,  20  dB  per  decade  of  frequency)  of 
the  free-space  single-ray  signal.  The  1/r^  roll-off  of  the  two-ray  model  is  40  dB  per  decade. 

The  equations  for  computing  the  two-ray  model  can  be  found  online,  in  text  books,  or 
from  direct  computation.  If  path  loss  software  is  available,  it  is  convenient  to  compute  the  two- 
ray  results  for  a  particular  situation  by  setting  the  terrain  height  to  zero  and  using  the  default 
value  of  ground  electrical  conductivity  provided  by  the  software. 


“  Thomas  Schwengler.  “Wireless  &  Cellular  Communications.  Class  notes  for  TLEN-5510  -  Fall  2016.  Accessed 
27  July  2017.  Available  at  http://morse.colorado.edu/~tlen5510/text/classwebch3.html. 
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Although  the  equations  for  the  two-ray  model  can  be  rather  daunting,  in  its  simplest  form, 
one  uses  flat-earth  trigonometry  to  compute  the  difference  in  path  lengths  between  the  direct  and 
reflected  signals.  This  depends  on  the  horizontal  distance  d,  the  altitude  of  the  aircraft  ht,  and  the 
height  above  ground  of  the  AMT  receive  antenna,  hr.  Using  trigonometry  and  assuming  that  the 
signal  is  reflected  from  the  ground  and/or  sea  with  a  reflection  coefficient  of  magnitude  1,  the 
aircraft  altitudes  and  locations  can  be  computed  for  which  positive  and  negative  signal 
reinforcement  due  to  multipath  occur.  When  the  direct  path  and  the  reflected  path  differ  by  an 
even  number  of  signal  half-wavelengths  X/2,  signal  reinforcement  occurs.  When  they  differ  by 
an  odd  number  of  half-wavelengths,  deep  fades  occur. 

For  reflections  from  a  smooth  ocean  surface,  the  conductivity  of  salt  water  can  be  used; 
however,  Rec  M.1459  anticipates  this,  and  most  interference  to  AMT  ground  station  paths  are 
not  over  water.  Hence,  the  default  value  for  ground  conductivity  is  typically  the  correct  value  to 
use. 


The  equation  for  computing  the  curve  shown  in  Figure  F-8  is  given  by 


■Itt  \  lo 


+  r 


cxi)0'‘27r/o/A) 


(F-9) 


Where  lo  and  I'o  are  the  line-of-sight  distances  I  and  x  +  x’  shown  in  Figure  F-7. 

With  respect  to  the  phrase  “direct  line  of  sight”,  it  is  convenient  to  note  that  this  is 
computed  as 

Dlos  —  ^  Vs  ^  J^^2^earth  ^  Vs  (F-10) 

where  hi  and  hi  are  the  heights  of  the  transmit  and  receive  antennas,  Rearth  is  the  nominal 
radius  of  the  earth  of  6358  km,  and  the  factor  of  4/3  accounts  for  atmospheric  refraction. 

Example  6.  Rayleigh  fading  of  the  aircraft  telemetry  signal 

There  is  a  generalization  of  the  two-ray  model  that  adds  the  effects  of  reflections  of  the 
telemetry  signal  from  aircraft  structures  and/or  blockage  of  the  telemetry  signal  by  these  same 
structures  during  aircraft  maneuvers.  This  is  Rayleigh  scattering  that  plays  an  important  role  in 
the  technical  details  of  Rec  M.1459.  The  resulting  Rayleigh  distribution  can  be  used  to  predict 
the  percentage  of  time  that  the  link  margin  of  any  air-to-ground  telemetry  link  will  fall  below  the 
threshold  value  needed  for  the  link  to  be  viable.  This  is  illustrated  by  Figure  F-9,  Figure  F-10, 
and  Figure  F-11. 
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Figure  F-9.  Rayleigh  Fading  of  a  Signal  Transmitted  from  a  Moving 
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Figure  F-10.  S-band  Telemetry  Signal  Received  from  an  Aircraft  in 

Flight®^ 


Wikipedia.  “Rayleigh  fading.”  Retrieved  27  July  2017.  Available  at 
https://en.wikipedia.org/wiki/Ravleigh  fading 

“  D.G.  Jablonski.  “Demonstration  of  Closed  Loop  Steering  of  Antenna  Patterns  for  Mitigating  Antenna-to- Antenna 
Interference  in  Two- Antenna  Telemetry  Installations  on  Military  Aircraft,”  Instrumentation  Test  Technical 
Symposium,  New  Orleans,  LA,  25  August  2004. 
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Airborne  telemetry  transmitting  antenna  gains,  Gj 


G,  (dBi) 

#  Antenna  type  No.  1 
A  Antenna  type  No.  2 
□  Antenna  type  No.  3 

Figure  F- 1 1 .  Rayleigh  Distribution  as  Presented  in  Figure  2  of  Rec 
M.1459  (Jablonski  2004). 

Figure  F-9  is  a  one-second  time  slice  of  the  strength  of  a  Rayleigh-faded  signal  as 
received  from  a  moving  transmitter.  Figure  F-10  is  the  measured  signal  strength  of  a  Rayleigh- 
faded  aircraft  telemetry  signal  as  a  function  of  time  as  received  at  an  AMT  ground  station. 

Figure  F- 1 1  relates  the  depth  of  a  fade  to  a  numerical  value  of  the  probability  as  a 
percentage  of  time  that  such  a  fade  will  occur.  The  mathematical  expression  given  in  the  figure 
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is  an  essential  component  of  the  computations  of  the  Rec  M.  1459  protection  criteria. 
Specifically,  the  Rayleigh  distribution  provides  the  connection  between  interference  and  link 
availability.  This  is  an  extension  of  less-sophisticated  link  budgets  that  consider  only  the  effect 
of  interference  on  BER,  without  considering  whether  the  interference  will  cause  the  link  to  fail 
completely. 

Note  that  the  Rayleigh  distribution  presented  above  is  typically  used  in  AMT  link  budget 
computations  by  including  the  fade  in  the  instantaneous  value  of  the  gain  Gxmt  of  the  aircraft 
telemetry  transmit  antenna,  as  opposed  to  including  it  as  a  component  of  the  path  loss.  This 
keeps  the  consideration  of  fading  due  to  aircraft  geometry  and  motion  independent  of  the 
consideration  of  terrain  effects  (described  below),  for  which  Rayleigh  scattering  is  typically  not 
relevant. 

Rec  M.1459  requires  a  threshold  signal-to-noise  value  of  (C/N)t  of  15  dB.  For  the  AMT 
system  values  specified  in  Rec  M.1459,  the  AMT  channel  bandwidth  is  3  MHz  and  the  system 
noise  temperature  is  250  Kelvin.  The  required  AMT  telemetry  signal  receive  power  is 


C  =  kTBx  10^-^  =  1.38  X  - 
3.27  X 


10  Joule  ^  , 

- p - X  250  Kelvin  x  (3  x  10^  Hz)  = 

Kelvin 

Watts  =  -124.85  dBW. 


(F-lla) 


The  corresponding  expression  for  the  Friis  equation  for  an  aircraft  antenna  transmit  gain 
of  -25  dB  and  including  the  effective  area  of  ^?Grec/4nof  the  AMT  ground  station  receive 
antenna  with  Pt=  3W,  Grec  =  41.2  dB,  r  =  320  km,  and  A,  =  0.2  meter  (per  Rec  M.1459)  is 


PjGj??  Gygc 

(47rr)2 


3xl0“2'®x(.2)^xl0^'^2 

(47r)2x(320xl03)2 


=  3.09  X  10-1^  Watts  =  -125.10  dBW 


(F-llb) 


Example  7:  Computation  of  path  loss  using  commercial  software  that  implements  the 
F-R/ITM  and  P.452  models 

Since  the  two-ray  model  is  seldom  adequate  for  predicting  path  loss  over  terrain,  a  wide 
assortment  of  models  that  include  the  effects  of  terrain  has  been  developed.  These  are  based  on 
different  combinations  of  assumptions  regarding  reflection,  refraction,  diffraction,  signal 
blockage,  Fresnel  zone  impingement,  etc.,  and  are  available  with  terrain  databases  already 
included.  These  include  several,  such  as  Terrain-Integrated  Rough-Earth  Model,  F-R,  ITM,  and 
Free- space  plus  reflection  and  multiple  diffraction. 

Another  category  of  models  is  contained  in  ITU-R  recommendations  that  are  similar  in 
structure  to  Rec  M.1459.  Three  of  the  most  important  models  are: 

•  P.452-16:  Prediction  procedure  for  the  evaluation  of  interference  between  stations  on  the 

surface  of  the  Earth  at  frequencies  above  about  0.1  GHz;^^ 


“  International  Telecommunication  Union.  “Prediction  procedure  for  the  evaluation  of  interference  between 
stations  on  the  surface  of  the  Earth  at  frequencies  above  about  0.1  GHz.”  ITU-R  Recommendation  P.452-16.  July 
2015.  May  be  superseded  by  update.  Retrieved  30  March  2017.  Available  at  https://www.itu.int/rec/R-REC- 
P.452/en. 
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•  P.1546:  Method  for  point-to-area  predictions  for  terrestrial  services  in  the  frequency 

range  30  MHz  to  3  000  MHz;®’ 

•  P.528:  Propagation  curves  for  aeronautical  mobile  and  radionavigation  services  using  the 

VHP,  UHF,  and  SHF  bands.®^ 

As  this  example  only  makes  use  of  the  L-R/ITM  and  P.452  models,  information 
regarding  the  other  two  models  is  excluded  from  this  document.  The  P.452  model  can  be 
regarded  as  the  internationally  approved  version  of  the  ITM,  which  is  an  outgrowth  of  the  L-R 
model.  The  ITM  and  L-R  models  were  developed  for  domestic  purposes  by  the  United  States  at 
the  National  Institute  of  Standards  and  Technology.  Because  of  the  need  for  technical  studies 
presented  to  the  ITU  to  utilize  ITU-sanctioned  models,  P.452  has  become  the  de  facto  standard 
for  domestic  studies  that  require  path  loss  computations  based  on  actual  terrain. 

In  order  to  use  P.452,  it  is  necessary  to  purchase  a  commercial  software  package  such  as 
EDX  Signal  Pro  (favored  by  the  AMT  community  at  the  present  time),  ATOLL  (used  by  cellular 
carriers),  or  Visualyse  (used  by  those  who  need  to  consider  platform  motion  and  the  time- 
dependent  effects  of  this  on  interference).  Such  commercial  packages  typically  include  most, 
and  sometimes  all,  of  the  models  listed  here. 

There  is  also  a  non-commercial  version  of  P.452,  in  the  form  of  macro-enabled  Excel 
spreadsheets,  that  is  available  free  of  charge  from  the  ITU  at  www.itu.int.  It  models  the  effects 
of  terrain  using  data  imported  from,  readily  available  terrain  databases. 

Eor  AMT,  the  fundamental  terrain  database  is  usually  the  government-provided,  freely 
available  USGS  1  arc-second  (30  meter)  resolution  topographic  map  data.  The  Shuttle  Radar 
Topography  Mission  database  is  sometimes  used,  although  it  is  comprised  of  overhead 
measurements,  and  its  validity  for  computing  point-to-point  path  loss  is  sometimes  questioned. 

It  is  important  to  consider  how  accurate  these  propagation  models  are.  A  comparison 
study ®^  suggests  that  error  bars  of  15  dB  in  the  path  loss  computation  are  typical.  Perhaps  a 
better  approach  is  to  use  existing  measurement  data  from  NTIA,’®  which  exist  in  the  form  of  five 
separate  studies  that  are  available  from  the  Defense  Technical  Information  Center.  It  is 
straightforward  to  insert  the  location,  frequency,  and  antenna  height  details  provided  in  the 
studies  into  any  of  the  commercial  models  for  comparison  purposes. 

Eigure  P-12  and  Pigure  P-13  illustrate  how  data  obtained  using  a  commercial  package,  in 
this  case  EDX  Signal  Pro,  are  presented  for  a  series  of  point-to-point  links  between  cellular 
towers  and  an  AMT  receive  site  at  Pax  River.  The  purpose  of  the  simulation  is  to  compute  path 
loss  values  from  each  of  the  cellular  sites  to  the  AMT  ground  station.  The  assumption  that  Pax 


International  Telecommunication  Union.  “Method  for  point-to-area  predictions  for  terrestrial  services  in  the 
frequency  range  30  MHz  to  3  000  MHz.”  ITU-R  Recommendation  P.1546-5.  September  2013.  May  be  superseded 
by  update.  Retrieved  30  March  2017.  Available  at  https://vv'vv'vv'.itu.int/rec/R-REC-P.  1546/en. 

International  Telecommunication  Union.  “Propagation  curves  for  aeronautical  mobile  and  radionavigation 
services  using  the  VHP,  UHF,  and  SHF  bands.”  ITU-R  Recommendation  P.528-3.  February  2012.  Maybe 
superseded  by  update.  Retrieved  30  March  2017.  Available  at  httt)s://vv'vv'vv'.itu.int/rec/R-REC-P.528/en. 

®  Phillips,  C.,  D.  Sicker,  and  D.  Grunwald.  “Bounding  the  Practical  Error  of  Path  Loss  Models.”  International 
Journal  of  Antennas  and  Propagation,  Volume  2012  (2012).  Retrieved  21  March,  2017.  Available  at 
https  V/yy  yy  yy  .hindawi.  com/i  ournals/ii  at)/20 12/754158/. 

For  example,  Hufford,  G.  A.  and  F.  K.  Steele.  “Tabulations  of  Propagation  Data  over  Irregular  Terrain  in  the  75- 
To  8400-Mhz  Frequency  Range  -  Part  V:  Virginia.  NTIA  Publication  91-282,  December  1991.  Retrieved  27  July 
2017.  Available  at  https://www.its.bldrdoc.gov/publications/download/91-282.pdf. 
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River  is  the  transmitter  site  is  a  feature  of  the  software  package’s  point-to-multipoint  analysis 
routine.  Since  the  purpose  of  the  analysis  is  to  compute  a  value  for  the  path  loss  for  each  link, 
including  the  effects  of  terrain,  reversing  the  roles  of  transmitter  and  receiver  is  of  no  numerical 
consequence. 


Figure  F-12.  EDX  Signal  Pro  Map  of  Hypothetical  Transmitters  and 
Receivers  in  the  Pax  River  Region. 


Figure  F-13.  EDX  Signal  Pro  Path  Eoss  Profile  for  the  TX007  to  RX007 

Path 


The  simulation  results  of  Eigure  P-12  and  Pigure  P-13  are  followed  in  Pigure  P-14  by 
experimental  data  measured  by  NTIA  engineers  and  reported  in  Hufford  and  Steele. 
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The  site  is  on  the  edge  of  a  rural  road;  the  path  crosses  a  plowed  field  before  reaching 
trees  500  m  ahead. 


Figure  F-14.  Actual  Measured  Path  Loss  Data  from  an  NTIA  Report  (cf. 

footnote  71) 

Figure  F-12  is  a  map  showing  various  point-to-point  transmitter- to-receiver  links,  TXOOl 
to  RXOOl,  TX002  to  RX002,  etc.  On  the  map,  the  same  geographic  location  is  used  for  all  the 
transmitters,  with  the  active  transmitter  for  the  example  analysis  (TX008)  displayed  on  top  of  the 
other  transmitters.  Map  data  such  as  this  is  essential  for  computing  aggregate  interference  as  a 
function  of  bearing  angle  to  an  AMT  site. 

Figure  F-13  shows  the  terrain  profile,  including  the  effects  of  the  earth’s  curvature,  for 
the  TX007-to-RX007  data  link.  The  path  loss,  computed  in  this  example  using  the  L-R  model,  is 
169.95  dB.  The  dashed  blue  line  represents  the  extent  of  the  Fresnel  zone,  showing  how  the 
terrain  blockage  impinges  the  zone,  thus  creating  excess  path  loss. 

For  these  simulations,  it  is  typically  appropriate  to  use  average  value  settings  for 
parameters  related  to  variability.  Although  actual  values  for  terrain  blockage  are  used 
throughout  the  simulation,  it  is  necessary  to  make  a  similar  (e.g.,  average)  assumption  about 
whether  diffraction  due  to  terrain  is  modeled  as  knife-edge  versus  smooth-edge  model. 

In  any  case,  it  is  important  to  validate  model  simulations  using  actual  measurements 
wherever  possible.  This  is  the  purpose  of  including  Figure  F-14,  which  is  an  example  path 
profile  from  the  many  measurements  made  by  NTIA. 

The  terrain  data  in  Figure  F-14  was  obtained  from  manual  inspection  of  a  topographic 
map  by  members  of  the  NTIA  team,  and  was  hand-entered  into  the  graphing  software  used  for 
preparing  the  measurement  report.  This  is  an  important  point.  In  interference  studies,  it  is  often 
the  case  that  only  a  few  cellular  towers  or  other  interference  sources  cause  the  aggregate  level  of 
interference  to  exceed  Rec  M.1459  limits.  It  is  possible  to  re-create  the  data  used  in  a 
commercial  package  by  reference  to  a  local  topographic  map  and  enter  the  data  in  the  ITU-R 
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P.452  spreadsheet  for  analysis.  The  results  are  as  accurate  as  those  produced  by  the  expensive 
packages,  but  can  be  obtained  by  using  Excel  spreadsheets. 

Given  the  major  effort  required  to  collect  experimental  data,  it  is  generally  not  practical 
to  make  measurements  at  all  of  the  frequencies  of  interest  with  respect  to  interference 
computation.  It  might  well  be  the  case  that  the  path  loss  at  1500  MHz,  rather  than  the  loss  at  the 
measured  frequency  of  2180  MHz,  is  the  value  of  interest. 

Since  the  wavelength  is  a  component  of  the  path  loss  value,  and  since  the  wavelength 
depends  on  the  signal  frequency,  it  is  necessary  to  consider  how  to  convert  a  measurement  made 
at  one  frequency  to  an  estimate  of  path  loss  at  a  different,  but  relatively  close,  value  of 
frequency,  such  as  the  2180-MHz  to  1500-MHz  example  given  here. 

To  a  first  approximation,  path  loss  is  independent  of  frequency  in  the  1-6  GHz  bands, 
although  effects  of  building  attenuation  are  significant  and  signal  absorption  by  foliage  becomes 
important  at  the  higher  end  of  this  frequency  range.  At  even  higher  frequencies,  such  as  the 
12.6-MHz  carrier  frequency  used  for  satellite  television  downlinks,  foliage  and  rain  attenuation 
are  both  significant.  At  even  higher  frequencies  atmospheric  absorption  due  to  water  vapor  is 
extremely  important,  and  care  is  often  taken  to  operate  in  windows  in  the  35-GHz  and  90-GHz 
ranges. 

The  explicit  inclusion  of  a  value  for  X  in  equation  F-2  for  the  path  loss  is  a  computational 
artifact.  In  the  Friis  equation,  it  more  properly  connects  the  gain  Grec  of  the  receive  antenna  to  its 
effective  area  A^Grec/4n:.  Shifting  X'^  from  the  effective  area  to  the  path  loss  portion  of  the 
equation  makes  the  path  loss  a  dimensionless  parameter,  which  is  necessary  in  order  for  its  value 
to  be  specified  in  dB. 

Thus,  when  a  path  loss  value  for  2180  MHz  is  used  as  an  estimate  for  the  path  loss  at 
1500  MHz,  it  is  necessary  to  correct  the  path  loss  value  using  equation  F-12. 

path  lossisQo  =  {^  s  /  x  P<7t/i /0SS2180  (F-12) 


Example  8.  Consideration  of  the  antenna  patterns  of  terrestrial  cellular  base  stations 

It  is  necessary  to  know  specific  details  of  the  gain  pattern,  location,  height  above  ground, 
and  pointing  direction  of  the  interfering  antenna  in  order  to  replicate  the  computation  for  the  case 
of  a  terrestrial  interferer.  If  the  terrestrial  interferer  is  a  cellular  tower  that  hosts  multiple 
sectored  antennas,  this  requires  specific  knowledge  about  the  antennas  that  are  used  and  how 
their  electronic  adjustments,  specifically  electrical  down-tilt,  are  configured. 

This  example  requires  the  equation  for  computing  the  bearing  angle  from  a  cellular  tower 
to  an  AMT  site,  and  vice  versa,  when  the  latitude  and  longitude  of  each  are  specified.  This  is 
done  using  the  mathematics  of  spherical  trigonometry  for  the  great  circle  arc  that  leads  from  one 
site  to  the  other. 

Then,  using  the  sector  antenna  pointing  angles  relative  to  true  north,  the  gain  of  each 
sectoral  antenna  on  the  tower  in  the  direction  of  the  AMT  site  is  derived.  The  gain  of  tower- 
mounted  cellular  antennas  may  be  specified  as  two  pattern  files,  one  for  a  360°  horizontal  sweep 
at  zero  degrees  elevation,  and  one  for  a  360°  vertical  sweep  at  zero  degrees  of  azimuth  with 
respect  to  the  main  lobe  of  the  antenna. 
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To  further  complicate  the  problem,  the  main  beam  of  each  sectoral  antenna  can  be 
pointed  downward  by  varying  increments  of  angle  (e.g.,  0-9  degrees)  by  remote  control  using 
the  electrical  down-tilt  feature  of  the  antenna.  For  the  cellular  antennas  of  interest,  each 
permissible  value  of  down-tilt  is  accompanied  by  its  own  pair  of  pattern  files. 

Mechanical  down-tilt  can  also  be  used.  This  requires  modifying  the  indexing  of  entries 
in  the  vertical  file  for  the  antenna  so  that,  for  example,  the  vertical  pattern  gain  entries  are  shifted 
by  the  amount  of  the  mechanical  down-tilt. 

The  purpose  of  down-tilt  is  to  permit  adjustment  of  patterns  to  improve  coverage  of  a 
typically  urban  or  suburban  area  as  new,  additional  cellular  towers  are  in-filled,  e.g.,  when  a 
network  is  expanded  to  maintain  coverage  while  increasing  capacity. 

In  any  case,  it  is  necessary  to  combine  the  two-dimensional  horizontal  and  vertical 
patterns  into  a  single  three-dimensional  pattern  using  an  interpolation  algorithm.  Manufacturers 
of  cellular  antennas  of  interest  are  not  the  main  source  of  advice  on  how  to  do  this.  Instead,  the 
academic  literature  summarizes  and  compares  four  different  algorithms.  These  are  called: 


•  Arithmetic  mean; 

•  Bi-linear  interpolation; 

•  Weighted  bi-linear  transformation; 

•  Horizontal  projected  interpolation. 

With  respect  to  the  antenna  pattern  files.  Overt  and  Ghoriz,  9  represents  elevation  (with 
positive  0  in  the  downward  direction  from  0  =  0  at  the  horizon)  and  the  azimuth  (j)  equals  0  in  the 
center  of  the  main  lobe  (with  positive  (j)  going  counterclockwise  as  viewed  from  above). 

The  formula  for  the  arithmetic  mean  is  the  simplest,  and  is  given  by: 

G(0,0)  =  V2  (Gvert(0)  +  Gnorizm  (F-13) 

The  equations  for  the  second  and  third  algorithms  are  rather  complicated,  and  are  not 
repeated  here. 


The  final  algorithm,  horizontal  projected  interpolation,  is  used  by  one  of  the  major 
commercial  software  packages.  It  has  also  been  incorporated  into  an  AFTRCC -developed 
production-grade  interference  analysis  software  package.  The  algorithm  is  given  by: 


G(0,  0)  =  G^(0)  -  •  (G^(0)  -  G^(9))  +  ^  ■  (G^(7r)  -  G^(n  -  0))]  (F-14) 


It  is  necessary  to  determine  the  appropriate  values  of  (j)  and  0  to  use  the  interpolation 
algorithms.  These  are  often  generated  by  the  software  package  that  is  used  to  compute  the  path 
loss  between  the  AMT  site  and  the  individual  cellular  tower.  Typically,  the  elevation  angle  0  is 
close  enough  to  being  horizontal  that  it  can  be  assumed  to  be  zero.  Given  that  the  angular 
resolution  of  the  pattern  files  is  only  one  degree  and  that  Gv(0°)  is  approximately  equal  to 
Gv(l°),  this  is  a  reasonable  approximation. 


Sign  conventions  for  0  and  (|)  should  be  verified  for  each  case  by  inspection  of  the  antenna  files  and  cross¬ 
checking  with  the  manufacturer’s  data  sheets. 
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Even  when  the  azimuth  angle  f  is  produced  by  the  path  loss  software,  it  is  helpful  to  use 
the  formula  below  to  confirm  that  no  data  entry  errors  that  would  change  the  value  of  azimuth 
have  occurred.  This  is  done  using  the  following  formula  from  spherical  trigonometry: 


sm(0)  = 


cosQatitudeAMr) 


■  sin^longitudeceii  —  longitude  (F-15) 


Note  that  (j)  represents  the  azimuth  angle  from  the  cellular  tower  to  the  AMT  ground 
station  antenna.  For  computing  the  gain  of  the  cellular  antenna  in  the  direction  of  the  AMT 
antenna,  the  direction  that  each  sectoral  antenna  mounted  on  the  tower  is  pointed  with  respect  to 
north  must  be  added  (or  subtracted,  as  appropriate)  to  compute  the  sectoral  antenna’s  bearing  to 
the  AMT  ground  station. 

As  shown  in  the  next  example,  when  computing  aggregate  interference  from  an  ensemble 
of  cellular  towers,  it  is  necessary  to  compute  the  bearing  of  the  AMT  site  to  each  cellular  tower 
and  the  angular  offset  of  this  bearing  from  the  main  lobe  of  the  AMT  antenna.  This  is  done  by 
reversing  the  roles  of  the  AMT  site  and  the  cellular  tower  in  the  above  equation. 


Alternatively,  the  reverse  bearing  can  be  computed  directly  from  (j)  for  the  cellular  tower, 
but  certain  quadrant  conventions  are  needed  in  order  to  resolve  ambiguities  between  the  bearing 
angle  (t)amt  and  its  complement  180  -  (t)amt.  This  issue  is  typically  discussed  in  basic  satellite 
communication  textbooks,  and  is  resolved  by  depicting  a  simple  drawing  of  the  cellular  tower 
and  AMT  site  locations  on  a  chart.  When  processing  hundreds  of  tower-to-AMT  locations  at 
once,  the  quadrant  correction  must  be  programmed  carefully. 

As  always,  care  must  be  taken  to  not  inadvertently  default  to  the  equations  of  flat-earth 
trigonometry.  In  this  limit,  the  elevation  angles  to  an  aircraft  from  a  cellular  tower  are  always 
overstated,  leading  to  a  misapplication  of  the  Rec  M.1459  protection  criteria. 

Example  pattern  files  can  be  found  online.’^  It  is  common  for  the  files  to  give  a 
maximum  value  of  the  gain  at  the  center  of  the  main  beam  of  the  pattern.  The  file  entries  then 
correspond  to  the  relative  attenuation  of  the  pattern  relative  to  this  value  of  Gmax- 

Example  9.  Aggregation  of  interference  from  a  network  of  cellular  base  stations  to  one  or 
more  AMT  ground  stations 

The  large-scale  simulation  of  interference  from  thousands  of  cellular  base  stations  and 
their  associated  handsets  will  be  a  major  activity  for  both  the  civil  and  DoD  AMT  communities 
as  government  spectrum  is  auctioned  for  use  by  commercial  broadband  carriers.  This  example 
presents  a  stand-alone,  step-by-step  procedure  for  accomplishing  this.  It  can  be  implemented  in 
a  variety  of  ways,  including  as  a  collection  of  Excel  spreadsheets  in  conjunction  with  the 
commercial  software  packages  (e.g.,  EDX  Signal  Pro)  referenced  earlier  in  this  appendix. 

The  steps  for  completing  a  coordination  of  a  large  collection  of  emitters  with  a  single 
AMT  ground  station  are  as  follows. 


CommScope.  “Calculators  and  Tools.”  Retrieved  11  July  2017. 
http://www.commscope.com/Resources/Calculators/. 

Analysis  of  the  aggregation  of  handsets  requires  the  inclusion  of  statistical  parameters  that  are  developed  in 
example  10.  The  analysis  of  an  aggregation  of  handsets  is  provided  in  example  12. 
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1.  The  composite  AMT  ground  station  antenna  pattern  provided  by  equations  1(a)  -  1(f)  of 
Rec  M.  1459^^^  is  used  instead  of  patterns  obtained  on  a  site-specific  basis  for  each  of  the 
hundreds  of  AMT  ground  stations  in  the  United  States.  This  composite  pattern  is  shown  in 
Figure  F-15.  Use  of  this  composite  antenna  pattern  addresses  several  features  unique  to  AMT 
operations  and  eliminates  the  need  for  detailed,  site-specific  technical  details  that  are  subject  to 
change  from  one  flight- test  program  to  another,  or  even  during  individual  test  flights.  The  Rec 
M.  1459  pattern  is  to  be  used  in  lieu  of,  for  example,  the  Wolfgain  and  Statgain  patterns  given  in 
NTIA  Report  TM-13-489^^,  although  the  Rec  M.  1459  composite  patterns  are  closely  related  to 
the  Statgain  patterns,  as  shown  later  in  this  appendix. 


Figure  F-15.  Composite  AMT  Pattern  from  Rec  M.  1459 


2.  Instead  of  traditional  interference-to-noise  ratio  (FN)  criteria,  interference  received  at  an 
AMT  ground  station  is  to  be  computed  using  the  appropriate  PFD  limit  from  Rec  M.1459.  For 
example,  this  might  be  the  Rec  M.  1459  PFD  limit  for  0-2°  angles  of  arrival  (with  respect  to 
the  horizon)  for  L  or  S  bands,  namely  -180  or  -181  dB  W/m^  in  4  kHz.  These  levels  represent 
the  total  permitted  aggregate  interference,  as  computed  using  the  technique  given  in  steps  3-5. 

3.  It  is  necessary  to  consider  the  interference  from  all  directions  with  respect  to  the  ground 
station  antenna,  including  interference  received  through  the  side  lobes  and  back  lobes  to  compute 
aggregate  interference.  Furthermore,  this  aggregate  interference  must  be  recomputed  for  all 
possible  pointing  angles  (in  azimuth)  of  the  AMT  ground  station  antenna,  which  can  rotate  to 
point  in  any  direction.  It  would  be  appropriate,  for  example,  to  compute  aggregate  interference 
for  each  of  720  pointing  angles,  measured  in  0.5°  increments. 

4.  To  compute  aggregate  interference  from  hundreds  of  base  stations,  for  example,  it  is 
necessary  to  group  the  eNodeBs  into  0.5°-wide  azimuth-of-arrival  wedges,  then  to  compute  the 
aggregate  PFD  per  wedge  for  each  of  these  for  each  of  720  possible  pointing  angles  of  the  AMT 


The  antenna  pattern  shown  in  Figure  1  of  Rec  M.  1459  is  not  the  pattern  to  be  used  here. 

Wang,  C.  W.  and  T.  Keech.  Antenna  Models  For  Electromagnetic  Compatibility  Analyses,  NTIA  Report  TM-13- 
489.  October  2012.  Retrieved  21  March  2017.  Available  at  https://www.ntia.doc.gov/report/2012/antenna-models- 
electromagnetic-compatibilitv-analyses. 
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ground  station.  The  aggregate  PFD  values  for  each  wedge  are  converted  in  a  received  power 
value  using  the  composite  AMT  ground  station  antenna  pattern.  This  pattern,  including  values 
for  side  lobes  and  back  lobes,  provides  the  necessary  weighting  factors  for  converting  PFD 
values  in  W/m^  to  absolute  power  in  watts  (cf.  equations  1-3). 

5.  The  aggregate  power  levels  for  each  azimuth-of- arrival  wedge  are  summed  for  all  of  the 
wedges  into  a  single  value.  This  aggregate  value  is  computed  for  each  of  the  720  possible 
pointing  angles  of  the  AMT  ground  station  antenna.  Each  of  these  720  values  is  then  converted 
back  into  a  PFD  level  and  compared  with  the  PFD  limit  of  -180  or  -181  dBW/m^  in  4  kHz. 
This  yields  a  graph  and/or  table  of  interference  values  versus  azimuth  for  the  AMT  ground 
station,  as  shown  in  notional  form  in  Figure  F-16.  Note  that  the  scaling  of  the  full  bandwidth  of 
the  co-channel  or  adjacent  channel  interference  to  the  4-kHz  reference  bandwidth  of  the  Rec 
M.1459  protection  criteria  uses  the  same  linear  transformation  that  is  used  for  a  traditional  FN 
analysis. 
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Figure  F-16.  Aggregate  Interference  as  a  Function  of  AMT  Antenna 

Pointing  Angle 


6.  The  above  approach  is  summarized  quantitatively  in  the  equations  below,  which 
elaborate  on  those  presented  earlier,  and  are  re-stated  here  for  the  convenience  of  the  reader. 

•  The  value  of  wavelength  that  is  part  of  the  expression  for  the  effective  area  of  the 
AMT  ground  station  receive  antenna  is  grouped  with  the  1/4 nP  spreading  term,  which 
is  then  redefined  as  path  loss.  This  regrouping  then  permits  the  spreading  term  to  be 
replaced  with  a  single  term  that  includes  the  effects  of  spreading,  terrain  and  clutter 
loss,  Fresnel  zone  impingement,  and  ground  reflection.  The  numerical  computation  of 
values  for  this  composite  path  loss  value  is  independent  of  the  use  of  Rec  M.  1459. 

•  The  conversion  of  PFD  values  to  received  power  and  vice  versa  involves  the  scaling 

term  It  is  important  to  account  for  the  presence,  or  absence,  of  this  term  in  the 

equations  presented  below,  so  as  to  not  inadvertently  delete  it  or  count  it  twice.  This 
is  why  the  equations  below  err  on  the  side  of  redundancy;  it  is  easier  to  ignore  an 
unneeded  equation  than  to  re-derive  it. 


With  this  as  a  reference,  the  following  evolution  of  equations  should  prove  useful. 
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1 .  Start  with  the  free-space  Friis  equation.  Aejfh  the  effective  area  of  the  AMT  ground 
station  receive  antenna: 


Free  =  EIRP^mt  X  ^  X  (F-16) 

2.  Add  antenna  gains,  the  definition  of  antenna  effective  area,  and  the  definition  of  PFD  to 
arrive  at: 


Free  =  ^  =  Pfd„c  X  A,„  =  pfd„,  X  ^  (F-17) 

3.  Move  ! An  from  effective  area  term  and  group  with  the  term  per  the  traditional 
mathematical  definition  of  path  loss.  Terrain,  ground  reflection,  clutter,  and  Fresnel  zone  effects 
can  now  be  included  in  the  numerical  value  used  for  path  loss  in  subsequent  computations: 

Prec  =  PxmtG,mt  ><  ><  ^  =  Pf^rec  X  ^e//  =  Pfdrec  X  ^  (F-18) 

Pfdrec  X  ^  =  PrmtG^cmt  X  X  ^  =  P^rntG^mt  X  {.Path_L0Ss)  X  ^  (F-19) 

4.  The  gain  of  the  AMT  ground  station  receive  antenna,  Gr-eo  disappears  from  the  equations 
when  computation  of  the  PFD  level  at  the  AMT  ground  station  receiver  is  the  desired  result: 

T  2  ^  ^ 

Prec  =  pfdrec  X  =  P,mtG,mt  X  (Path_L0Ss)  X  ^  (F-20) 

pfdrec  PxmtGxmt  X  (^PCLth_L0SS^  X  (F-21) 


5.  Use  the  appropriate  eNodeB  antenna  gains  described  in  step  4  to  compute  PxmtGxmt- 
Use  the  speed  of  light  to  compute,  for  this  example,  the  wavelength  A,  corresponding  to  a 
frequency  of  1500  MHz.  Scale  the  EIRP  values  to  the  4-kHz  reference  bandwidth  of  the  Rec 
M.1459  PFD  protection  level.  This  yields  the  interference  from  a  single  handset  as  a  PFD  level 
measured  at  the  location  of  the  AMT  ground  station  antenna.  This  value  can  be  compared 
directly  with  the  protection  level  from  Rec  M.1459. 


Pfdrecijt^kii-^  —  (Interference  in  Watts  per  MHz')  x  G^mt  x  iPath_Loss)  x  — 
4000  Hz 
^  IMHz 


3  X  10« 
1500  X  10^ 


0.20  meter 


=  Interference  x  G^mt 


X  (Path_Loss)  X  x 


4000  Hz 
1  MHz 


(F-22) 


(F-23) 


6.  Now  that  the  relationships  between  interference  power,  path  loss,  PFD,  and  Prec  are 
defined,  the  aggregation  process  described  earlier  can  be  implemented.  The  important  point  is 
that  the  PFD  values  due  to  each  sector  of  each  cNodeB,  as  measured  at  an  AMT  ground  station 
location,  are  grouped  within  an  angle  of  arrival  wedge,  then  multiplied  by  the  appropriate  value 
of  AMT  composite  antenna  pattern  for  each  angle  of  arrival  value.  The  total  interference  from 
all  directions  for  each  possible  AMT  pointing  angle  is  computed,  then  changed  back  into  an 
aggregate  value  of  PFD  by  the  conversion  factor  47t:/A,^  to  arrive  at  a  single  value  of  aggregate 
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PFD  for  each  of  the  720  possible  AMT  antenna  pointing  angles.  Each  entry  in  this  table  of 
values  is  then  compared  with  the  protection  limit  from  Rec  M.  1459. 

7.  Finally,  note  that  interference  to  an  AMT  signal  is  typically  averaged  over  the  bandwidth 
of  the  affected  AMT  channel(s),  as  described  previously.  This  averaging  is  accomplished  in  the 
same  manner  that  would  apply  to  a  traditional  EN  analysis.  The  4-kHz  reference  bandwidth  in 
Rec  M.1459  must  be  scaled  to  correspond  to  AMT  channel  bandwidths  of  1  -  20  MHz,  with  5 
MHz  being  a  common  value  for  use  in  analysis. 

Example  10.  Additional  considerations  for  the  modeling  of  interfering  systems 

It  is  important  to  include  effects  such  as  network  load  factors,  transmitters  that  emit 
intermittently,  and  the  use  of  dynamic  power  control.  Note  that  there  are  no  similar  effects 
related  to  the  performance  of  AMT  operations  that  need  be  considered,  as  these  are  already 
captured  in  Rec  M.  1459.  Annex  2  of  Rec  M.  1459  accounts  for  signal  fades,  for  the  requirement 
of  a  minimum  value  of  telemetry  link  availability,  and  for  the  constantly  changing  location  of 
test  aircraft  in  the  sky  with  respect  to  both  satellite  and  terrestrial  interference  sources. 

Consider  Example  9,  coordination  of  an  AMT  ground  station  with  emissions  from  a  large 
network  of  cellular  towers.  The  cellular  industry  has  noted  repeatedly  that  its  networks  seldom 
operate  at  full  load  factor.  This  means  that,  averaged  over  several  weeks,  an  individual  cellular 
tower  is  transmitting  only  about  60%  of  the  time.  Cellular  proponents  thus  advocate  a  decrease 
in  the  computed  value  of  aggregate  interference  used  in  analysis  by  40%. 

The  decrease  in  cellular  tower  activity  at  off-peak  times  corresponds  with  time  slots 
where  flight  test  activities  are  also  at  a  minimum  (e.g.,  at  night).  Furthermore,  the  time  scales 
over  which  base  station  load  factors  are  averaged  (weeks)  have  no  correlation  with  the  time 
duration  of  interference  causing  an  AMT  link  to  fail  (fractions  of  a  second).  Short-term 
interference  can  cause  loss  of  antenna  tracking,  which  can  be  difficult  to  re-establish  without  the 
need  to  re-fly  test  points. 

The  point  is  that  when  the  probability  of  interference  depends  on  time,  it  is  necessary  to 
use  the  same  time  scales  for  analyzing  both  the  interfering  and  the  victim  systems.  In  the  case  of 
AMT  operations,  this  means  that  all  computations  need  to  be  performed  for  the  time  scale  that 
corresponds  to  the  interval  of  time  that  it  takes  an  interfering  signal  to  cause  loss  of  AMT 
telemetry  link  bit  synchronization.  As  stated  in  the  previous  paragraph,  this  is  not  weeks  or  days, 
but  fractions  of  a  second.  In  any  case,  loss  of  even  small  amounts  of  data  can  make  it  necessary 
to  re-fly  part,  or  even  all,  of  the  maneuvers  included  in  a  particular  test  flight. 

Coordination  of  AMT  ground  stations  with  emissions  from  cellular  handsets  introduces 
similar  issues.  These  handsets  use  dynamic  power  control,  in  which  a  cellular  tower  measures 
the  received  signal  from  a  handset  in  real  time  and  sends  instructions  to  the  handset  to  adjust  its 
transmit  power. 

In  addition,  ETE  and  WiMAX  (i.e.,  802.16)  systems  operate  by  using  orthogonal 
frequency  division  multiplexing,  in  which  data  are  coded  among  several  adjacent  frequency 
subcarriers  spread  across  the  10  -  20  MHz  ETE  bands. The  power  amplitudes  of  each 
subcarrier  vary  with  time,  yielding  variations  characterized  by  what  is  called  the  peak-to- 
average-power-ratio  (PAPR).  For  ETE,  the  PAPR  is  about  6  dB,  with  variations  occurring  on 


WiMAX  will  be  used  for  the  AeroMACS  system  at  5091-  5150  MHz,  co-channel  with  AMT. 
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the  order  of  milliseconds.  For  WiMAX,  the  PAPR  is  as  high  as  13  dB.  The  statistical 
distribution  as  a  function  of  time  for  each  system  is  characterized  by  a  complementary 
cumulative  distribution  function. 

It  remains  an  open  question  whether  PAPR  fluctuations,  which  include  reductions  as  well 
as  surges  in  transmit  power,  are  a  concern. 

Example  11.  Special  considerations  regarding  AMT  antennas 

The  use  of  a  composite  antenna  in  Rec  M.  1459  is  referenced  multiple  times  in  this 
appendix.  In  the  recommendation,  however,  the  development  of  the  composite  antenna  pattern  is 
described  in  the  body  of  Annex  A  only  for  the  case  of  lower  L-band,  which  has  a  pattern  that  is 
based  on  the  NTIA  Statgain  antenna  model  of  parabolic  dish  antennas  (Wang  and  Keech,  2012), 
and  is  derived  numerically  for  antennas  having  diameters  of  10  meters  and  2.44  meters.  The 
composite  pattern  is  derived  by  comparing  the  10-meter  and  2.44-meter  patterns  side-by-side  and 
choosing  the  value  of  gain  that  is  higher  for  a  given  off-axis  pointing  angle. 

Although  not  described  explicitly  in  the  recommendation,  the  antenna  pattern  was 
modified  for  the  purpose  of  computing  the  protection  criteria  for  upper  S-band  that  are  also 
published  in  the  recommendation.  The  L-  and  S-band  frequencies  are  sufficiently  close  in  value 
that  the  same  composite  pattern  can  be  used  for  both  bands  for  purposes  of  computing  aggregate 
interference.  This  is  a  result  of  certain  complex  convolution  computations  described  in  the 
methodology  provided  by  the  recommendation;  however,  this  simplification  does  not  apply  as 
telemetry  systems  are  deployed  at  C-band  and  higher  frequencies. 

To  address  the  computation  of  the  protection  criteria  for  upper  L,  lower  S,  and  lower, 
middle,  and  upper  C-bands,  new  composite  antenna  patterns  were  computed  using  the  NTIA 
Statgain  antenna  pattern  formulas  given  below. 

Although  the  antenna  patterns  are  not  needed  again  for  purposes  of  determining  the 
protection  criteria,  they  are  needed  when  computing  aggregation  from  large  numbers  of 
terrestrial  interferers.  For  this  purpose,  the  process  of  computing  composite  antenna  patterns  is 
straightforward,  and  is  described  below. 

With  respect  to  the  computation  of  composite  antenna  patterns,  the  gain  of  both  a  IO¬ 
meter  and  2.44-meter  diameter  dish  were  computed  for  each  band  using  the  Statgain  formulas 
with  the  gain  parameter  Gmax  for  each  dish  computed  using  the  formula 

=  0.55  X  (F-24) 

where  0.55  represents  the  nominal  efficiency  of  the  dish  antennas. 

Then,  using  the  equations  below,  patterns  were  computed  for  both  the  10-meter  and  2.44- 
meter  antennas  for  each  value  of  signal  wavelength  X.  Using  a  simple  spreadsheet,  the  gains  of 
the  two  antennas  as  a  function  of  off-axis  angle  for  each  value  of  X  were  compared.  The  higher 
gain  value  of  the  two  antennas  was  chosen  as  the  value  for  that  angle  for  the  corresponding 
composite  antenna.  Although  this  is  a  slight  simplification  of  the  side-lobe  averaging  technique 
used  in  the  recommendation,  the  impact  on  the  numerical  values  of  the  protection  criteria  was 
found  to  be  negligible.  This  means  that  for  computational  purposes,  the  Statgain  antenna 
patterns  can  be  used  for  C  and  higher  bands  without  modification. 
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In  addition  to  the  Statgain  formulas,  which  provide  an  envelope  function  for  the 
maximum  values  of  the  gain  pattern,  the  more  general  pattern  equations  are  also  provided. 

These  are  difficult  to  find  in  textbooks,  but  are  often  useful. 

The  Statgain  radiation  patterns,  G( (j)),  as  a  function  of  the  angle  from  the  main-beam  axis, 
(j),  are  shown  in  Table  F-1  (Wang  and  Keech  2012)  and  the  Statgain  envelope  pattern  is 
presented  in  Figure  F-17  (Wang  and  Keech  2012).  The  more  general  pattern  equations, 
published  as  part  of  the  Satellite  Toolkit  software,  are  provided  afterwards. 


Table  F-1.  Statgain  Formulas 

Category 

Gain((|))  (dBi) 

Angular  Range  (deg.) 

Gmax  >  48  dBi 

Gmax -4X10“^(10^™“^/1°)(|)2 

0  <  (j)  <  (j)m 

0.75  X  Gmax  -  7 

(j)m  <  (j)  <  (j)rl 

29  -  25  X  log((t)) 

(j)rl  <  (j)  <  (j)bl 

-13 

(j)bl  <  (j)  <  180° 

22  <  Gmax(dBi)  <  48 

Gmax -4xl0“^(10^™“^/l°)(|)2 

0  <  (j)  <  (j)m 

0.75  X  Gmax  -  7 

Om  O  ^  ()r2 

53  -  (Gmax  /2)  -  25  X  log((|)) 

(j)r2  <  (j)  <  (j)b2 

11  -Gmax/2 

(|)bl  <  (j)  <  180° 

10  <  Gmax(dBi)  <  22 

Gmax  -4x10“4(10^™“^/1°)(^2 

0  <  (|)  <  (t)m 

0.75  X  Gmax  -  7 

(j)m  <  (j)  <  (j)r3 

53  -  (Gmax  /2)  -  25  X  log((j)) 

(j)r3  <  (j)  <  (j)b3 

0 

(j)b3  <  (j>  <  180° 

All  angles  are  in  degrees. 

(j)m  =  50(0.25Gmax  +lf^l{lQ(^rnax/20~^ 

(j)ri  =  27.466xl0-°^^"‘“^/i° 

(j),i  =  (j),i  =  250/(10^"^“^/^°) 

(t)bl  =  (|)b2  =  48 

(j)b3  =  131.8257x10“^™“^/^°) 
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Note  that  the  Statgain  patterns  provide  an  upper  envelope  of  the  antenna  pattern.  The 
more-generalized  parabolic  dish  equations  are  available  as  part  of  the  Analytical  Graphics  (AGI) 
Satellite  Toolkit  software  tool.^^  These  equations  provide  details  about  the  peaks  and  nulls  of  the 
antenna  side-lobes  as  opposed  to  providing  an  envelope  of  the  pattern,  and  are  given  below. 

The  parabolic  antenna  parameters  are: 

d  =  diameter  of  the  parabolic  dish 

h=  wavelength 

The  gain  of  a  parabolic  antenna  is  modeled  by  the  equations  F-25a,  F-25b,  and  F- 
25c: 


X  = - sin  ^ 

^  (F-25a) 


Pe 


(F-25b) 


(F-25c) 


where  pe  =  the  antenna  efficiency,  (j)  =  angle  off  Foresight,  and  Ji  =  first-order  Bessel 
function.  This  model  is  for  a  uniformly  illuminated  circular  aperture  dish. 

On  a  final  note,  the  question  has  been  posed  of  how  to  compute  protection  criteria  for 
antennas  whose  diameter  falls  outside  the  range  of  2.44  -  10  meters.  The  simple  and  reasonable 
approach  is  to  recognize  that  both  the  gain  and  beamwidth  of  a  parabolic -dish  antenna  are  related 
to  the  parameter  D/A,.  For  the  case  of  an  antenna  that  is  13  meters  in  diameter  but  operating  at 
upper  L-band  (for  example),  D/A,  is  about  75.  This  is  comparable  to  a  10-meter  antenna 
operating  at  a  wavelength  of  0. 133  meters.  Since  the  protection  criteria  for  upper  S-band 
correspond  to  a  wavelength  of  0.128  meters,  it  seems  appropriate  to  use  the  protection  criteria  for 
upper  S-band  as  the  values  for  a  13-meter  diameter  antenna  operating  at  upper  L-band. 


Maral,  G.,  and  M.  Bousquet.  Satellite  Communications  Systems:  Systems,  Techniques  and  Technology.  2'“*  ed. 
Chichester:  Wiley  (1993),  sec.  2.1.3;  Gagliardi,  Robert  M.  Satellite  Communications.  2“‘‘  ed..  New  York:  Van 
Nostrand  Reinhold  (1991),  sec.  3.2. 


F-32 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  2,  July  2017 


APPENDIX  2-G 


Standards  for  Data  Quality  Metrics  and  Data  Quality  Encapsulation 

G.l.  Purpose 

This  appendix  provides  a  standard  for  a  DQM,  determined  in  the  telemetry  receiver 
demodulator,  and  a  standard  for  DQE  allowing  for  transport  of  the  received  telemetry  data  and 
associated  DQM  to  a  distant  best  source  selector  or  similar  device.  The  DQE  wrapper, 
commonly  referred  to  as  a  protocol,  will  enable  telemetry  receivers  to  generate  a  serial  data 
stream  that  will  include  a  standardized  measurement  of  the  real-time  probability  of  error  for  a 
grouping  of  bits. 

G.2.  Scope 

The  DQM  standard  describes  how  to  map  the  estimated  BEP  of  the  received  telemetry 
data  to  a  16-bit  word.  The  DQM  standard  does  not  define  how  the  telemetry  receiver  performs 
BEP  estimates.  The  DQE  standard  describes  how  to  format  the  received  telemetry  data  with  the 
associated  DQM  for  transport. 


G.3.  Data  Quality  Metric 


The  general  case  of  DQM  is  calculated  as  follows: 


DQM  = 


k 


*  2” 


where:  k  is  the  exponent  for  lowest  estimated  BEP 

n  is  number  of  bits  in  the  DQM  field 
LR  is  the  likelihood  ratio 


LR  = 


BEP 

(1  -  BEP) 


Eor  this  standard,  k=l2  and  n=16. 

In  formula  form  this  calculation  can  be  made  with  the  following  equation: 
D2M  =  MIN(ROUND(-EOG10(Li?)/12  *  (2^^),0),  2*^-1) 


a.  The  measurement  value  corresponds  to  the  average  quality  of  the  data  bits  in  the  payload. 

b.  The  DQM  value  is  associated  with  the  payload  bits  in  the  current  block  frame.  Table  G-1 
defines  ER  and  DQM  for  various  values  of  BEP. 


Table  G-1.  BEP  Verses  DQM 

BEP 

LR 

DQM 

0.5 

1.00 

0 

le-01 

l.llllle-01 

5211 

le-02 

l.OlOlOe-02 

10899 
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le-03 

l.OOlOOe-03 

16382 

le-04 

l.OOOlOe-04 

21845 

le-05 

l.OOOOle-05 

27307 

le-06 

l.OOOOOe-06 

32768 

le-07 

l.OOOOOe-07 

38229 

le-08 

l.OOOOOe-08 

43691 

le-09 

l.OOOOOe-09 

49152 

le-10 

l.OOOOOe-10 

54613 

le-11 

l.OOOOOe-11 

60075 

le-12 

l.OOOOOe-12 

65535 

It  is  not  required  that  BEP  be  estimated  to  the  le-12  level.  Estimates  to 
a  lesser  level  are  acceptable;  however,  the  format  above  shall  be  followed 
in  all  cases.  Eor  example,  if  estimating  BEP  to  the  le-8  level,  the 
applicable  range  of  DQM  values  shall  be  0  to  43691. 


G.4.  Data  Quality  Encapsulation  Protocol 


The  block  format  is  equivalent  to  a  fixed-length  PCM  frame.  Transmission  of  payload 
data  shall  be  first  in  -  first  out.  Transmission  of  other  fields  shall  be  most  significant  bit  first. 


16  Bits 

12  Bits 

4  Bits 

16  Bits 

1024  -  16384  Bits 

SW 

RSV 

VER 

DQM 

PAYEOAD 

a.  SW  =  Sync  Word.  The  sync  word  is  a  fixed  value  of  0xPAC4. 

b.  RSV  =  Reserved.  Reserved  for  future  use.  These  bits  shall  be  set  to  zero  (0)  until  used. 

c.  VER  =  IRIG  106  Version  number.  Version  number  shall  start  with  Version  0  (0000)  for 
IRIG  106-17. 

d.  DQM  =  Data  Quality  Metric.  This  field  will  contain  the  DQM  value  as  defined  in 
Section  G.3 

e.  PAYEOAD  =  Telemetry  data  payload  to  which  the  DQM  value  applies.  The  DQM  and 
the  data  payload  are  contained  in  the  same  block.  The  minimum  payload  size  shall  be 
1024  bits  and  the  maximum  size  shall  be  16,384  bits.  Payload  size  can  be  any  multiple  of 
32  bits  between  the  minimum  size  and  maximum  size. 
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FM 
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RF 
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CHAPTER  3 

Frequency  Division  Multiplexing  Telemetry  Standards 


NOTE 


This  chapter  contains  standards  for  analog  frequency  modulation  (FM)  data, 
specifically  dealing  with  frequency  division  multiplexing  and  subcarrier 
channels.  It  is  readily  apparent  that  the  use  of  analog  data  has  been 
superseded  by  digital  data  to  a  large  extent.  Therefore,  while  the  standards  in 
this  chapter  are  valid  for  any  and  all  FM  data  still  in  use,  further  development 
pertaining  to  FM  data  is  not  supported  or  encouraged. 


3.1  General 

In  frequency  division  multiplexing,  each  data  channel  makes  use  of  a  separate  subcarrier 
that  occupies  a  defined  position  and  bandwidth  in  the  modulation  baseband  of  the  radio 
frequency  (RF)  carrier.  Two  types  of  FM  subcarrier  formats  may  be  used.  The  data  bandwidth 
of  one  format  type  is  proportional  to  the  subcarrier  center  frequency,  while  the  data  bandwidth  of 
the  other  type  is  constant,  regardless  of  subcarrier  frequency. 

3.2  FM  Subcarrier  Characteristics 

In  these  systems,  one  or  more  subcarrier  signals,  each  at  a  different  frequency,  are 
employed  to  frequency-modulate  or  phase-modulate  a  transmitter  in  accordance  with  the  RF 
conditions  specified  in  Chapter  2.  The  following  subparagraphs  set  forth  the  standards  for 
utilization  of  FM  frequency  division  multiplexing. 

Each  of  the  subcarriers  conveys  measurement  data  in  FM  form.  The  number  of  data 
channels  may  be  increased  by  modulating  one  or  more  of  the  subcarriers  with  a  time-division 
multiplex  format  such  as  pulse  code  modulation. 

The  selecting  and  grouping  of  subcarrier  channels  depend  upon  the  data  bandwidth 
requirements  of  the  application  at  hand  and  upon  the  necessity  to  ensure  adequate  guard  bands 
between  ehannels.  Combinations  of  both  proportional-bandwidth  ehannels  and  constant- 
bandwidth  channels  may  be  used. 

3.3  FM  Subcarrier  Channel  Characteristics 

The  following  subparagraphs  deseribe  the  characteristics  of  proportional-bandwidth  and 
constant-bandwidth  FM  subcarrier  channels. 

3.3.1  Proportional-Bandwidth  FM  Subcarrier  Channel  Characteristics 

Table  3-1,  Table  3-2,  and  Table  3-3  list  the  standard  proportional-bandwidth  FM 
subcarrier  channels.  The  channels  identified  with  letters  permit  +15  or  +30  percent  subcarrier 
deviation  rather  than  +7.5  percent  deviation  but  use  the  same  frequencies  as  the  12  highest 
channels.  The  channels  shall  be  used  within  the  limits  of  maximum  subcarrier  deviation.  See 
Appendix  3- A  for  expected  performance  tradeoffs  at  selected  combinations  of  deviation  and 
modulating  frequency. 
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Table  3-1.  Proportional-Bandwidth  FM  Subcarrier  Channels  +7.5% 

Channels 

Channel 

Center 
Frequencies 
(hertz  [Hz]) 

Lower 
Deviation 
Limit  (Hz) 

LFpper 

Deviation 

Limit 

(Hz) 

Nominal 

Frequency 

Response 

(Hz) 

Nominal 

Rise  Time 

(millisecond 

[ms]) 

Maximum 

Frequency 

Response 

(Hz) 

Minimum 
Rise  Time 
(ms) 

1 

400 

370 

430 

6 

58 

30 

11.7 

2 

560 

518 

602 

8 

44 

42 

8.33 

3 

730 

675 

785 

11 

32 

55 

6.40 

4 

960 

888 

1032 

14 

25 

72 

4.86 

5 

1300 

1202 

1398 

20 

18 

98 

3.60 

6 

1700 

1572 

1828 

25 

14 

128 

2.74 

7 

2300 

2127 

2473 

35 

10 

173 

2.03 

8 

3000 

2775 

3225 

45 

7.8 

225 

1.56 

9 

3900 

3607 

4193 

59 

6.0 

293 

1.20 

10 

5400 

4995 

5805 

81 

4.3 

405 

0.864 

11 

7350 

6799 

7901 

no 

3.2 

551 

0.635 

12 

10,500 

9712 

11,288 

160 

2.2 

788 

0.444 

13 

14,500 

13,412 

15,588 

220 

1.6 

1088 

0.322 

14 

22,000 

20,350 

23, 650 

330 

1.1 

1650 

0.212 

15 

30,000 

27,750 

32,250 

450 

0.78 

2250 

0.156 

16 

40,000 

37,000 

43,000 

600 

0.58 

3000 

0.117 

17 

52,500 

48,562 

56,438 

788 

0.44 

3938 

0.089 

18 

70,000 

64,750 

75,250 

1050 

0.33 

5250 

0.06 

19 

93,000 

86,025 

99,975 

1395 

0.25 

6975 

0.050 

20 

124,000 

114,700 

133,300 

1860 

0.19 

9300 

0.038 

21 

165,000 

152,625 

177,375 

2475 

0.14 

12,375 

0.029 

22 

225,000 

208,125 

241,875 

3375 

0.10 

16,875 

0.021 

23 

300,000 

277,500 

322,500 

4500 

0.08 

22,500 

0.016 

24 

400,000 

370,000 

430,000 

6000 

0.06 

30,000 

0.012 

25 

560,000 

518,000 

602,000 

8400 

0.04 

42,000 

0.008 

See  notes  at  end  of  Table  3-3. 

Table  3-2.  Proportional-Bandwidth  FM  Subcarrier  Channel  +15% 

Channels 

Channel 

Center 

Frequencies 

(Hz) 

Lower 
Deviation 
Limit  (Hz) 

Upper 
Deviation 
Limit  (Hz) 

Nominal 

Frequency 

Response 

(Hz) 

Nominal 
Rise  Time 
(ms) 

Maximum 

Frequency 

Response 

(Hz) 

Minimum 
Rise  Time 
(ms) 

A 

22,000 

18,700 

25,300 

660 

0.53 

3300 

0.106 

B 

30,000 

25,500 

34,500 

900 

0.39 

4500 

0.078 

C 

40,000 

34,000 

46,000 

1200 

0.29 

6000 

0.058 
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D 

52,500 

44,625 

60,375 

1575 

0.22 

7875 

0.044 

E 

70,000 

59,500 

80,500 

2100 

0.17 

10,500 

0.033 

F 

93,000 

79,050 

106,950 

2790 

0.13 

13,950 

0.025 

G 

124,000 

105,400 

142,600 

3720 

0.09 

18,600 

0.018 

H 

165,000 

140,250 

189,750 

4950 

0.07 

24,750 

0.014 

I 

225,000 

191,250 

258,750 

6750 

0.05 

33,750 

0.010 

J 

300,000 

255,000 

345,000 

9000 

0.04 

45,000 

0.008 

K 

400,000 

340,000 

460,000 

12,000 

0.03 

60,000 

0.006 

L 

560,000 

476,000 

644,000 

16,800 

0.02 

84,000 

0.004 

See  notes  at  end  of  Tab 

le  3-3. 

Table  3-3.  Proportional-Bandwidth  FM  Subcarrier  Channels  +30% 

Channels 

Channel 

Center 

Frequencies 

(Hz) 

Fewer 
Deviation 
Eimit  (Hz) 

Upper 
Deviation 
Eimit  (Hz) 

Nominal 

Frequency 

Response 

(Hz) 

Nominal 
Rise  Time 
(ms) 

Maximum 

Frequency 

Response 

(Hz) 

Minimum 
Rise  Time 
(ms) 

AA 

22,000 

15,400 

28,600 

1320 

0.265 

6600 

0.053 

BB 

30,000 

21,000 

39,000 

1800 

0.194 

9000 

0.038 

CC 

40,000 

28,000 

52,000 

2400 

0.146 

12,000 

0.029 

DD 

52,500 

36,750 

68,250 

3150 

0.111 

15,750 

0.022 

EE 

70,000 

49,000 

91,000 

4200 

0.083 

21,000 

0.016 

FF 

93,000 

65,100 

120,900 

5580 

0.063 

27,900 

0.012 

GG 

124,000 

86,800 

161,200 

7440 

0.047 

37,200 

0.009 

HH 

165,000 

115,500 

214,500 

9900 

0.035 

49,500 

0.007 

II 

225,000 

157,500 

292,500 

13,500 

0.026 

67,500 

0.005 

JJ 

300,000 

210,000 

390,000 

18,000 

0.019 

90,000 

0.004 

KK 

400,000 

280,000 

520,000 

24,000 

0.015 

120,000 

0.003 

EE 

560,000 

392,000 

728,000 

33,600 

0.010 

168,000 

0.002 

Notes: 

1 .  Round  off  to  nearest  Hz. 


2.  The  indicated  maximum  data  frequency  response  and  minimum  rise  time  is  based  on  the 
maximum  theoretical  response  that  can  be  obtained  in  a  bandwidth  between  the  upper  and 
lower  frequency  limits  specified  for  the  channels.  See  Paragraph  A. 3  for  determining 
possible  accuracy  versus  response  tradeoffs. 

3.  Channels  A  through  L  may  be  used  by  omitting  adjacent  lettered  and  numbered  channels. 
Channels  13  and  A  may  be  used  together  with  some  increase  in  adjacent  channel 
interference. 

4.  Channels  AA  through  LL  may  be  used  by  omitting  every  four  adjacent  double  lettered  and 
lettered  channels  and  every  three  adjacent  numbered  channels.  Channels  AA  through  LL 
may  be  used  by  omitting  every  three  adjacent  double  lettered  and  lettered  channels  and  every 
two  adjacent  numbered  channels  with  some  increase  in  adjacent  channel  interference. 
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3.3.2  Constant-Bandwidth  FM  Subcarrier  Channel  Characteristics 

Table  3-4  lists  the  standard  constant-bandwidth  FM  subcarrier  channels.  The  letters  A, 

B,  C,  D,  E,  F,  G,  and  H  identify  the  channels  for  use  with  maximum  subcarrier  deviations  of  ±2, 
±4,  +8,  +16,  +32,  +64,  +128,  and  +256  kilohertz  (kHz),  along  with  maximum  frequency 
responses  of  2,  4,  8,  16,  32,  64,  128,  and  256  kHz.  The  channels  shall  be  used  within  the  limits 
of  maximum  subcarrier  deviation.  See  Appendix  3- A  for  expected  performance  tradeoffs  at 
selected  combinations  of  deviation  and  modulating  frequencies. 

3.4  Tape  Speed  Control  and  Flutter  Compensation 

Tape  speed  control  and  flutter  compensation  for  FM/FM  formats  may  be  accomplished  as 
indicated  in  Annex  A. 2,  Subsection  17.4.  The  standard  reference  frequency  used  shall  be  in 
accordance  with  the  criteria  in  Table  3-5  when  the  reference  signal  is  mixed  with  data. 
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Table  3-4.  Constant-Bandwidth  FM  Subcarrier  Channels 

Frequency  Criteria\Channels: 

A 

B 

C 

D 

E 

F 

G 

H 

Deviation  Limits  (kHz) 

±2 

±4 

±8 

±16 

±32 

±64 

±128 

±256 

Nominal  Frequency  Response  (kHz) 

0.4 

0.8 

1.6 

3.2 

6.4 

12.8 

25.6 

51.2 

Maximum  Frequency  Response  (kHz) 

2 

4 

8 

16 

32 

64 

128 

256 

Notes: 

Center  Frequency  (kHz) 

8 

16 

32 

64 

128 

256 

512 

1024 

The  constant-bandwidth  channel  designation 

16 

32 

64 

128 

256 

512 

1024 

2048 

shall  be  the  channel  center  frequency  in 

24 

48 

96 

192 

384 

768 

1536 

3072 

kilohertz  and  the  channel  letter  indicating 

32 

64 

128 

256 

512 

1024 

2048 

deviation  limit;  for  example,  16A,  indicating/c 

40 

80 

160 

320 

640 

1280 

2560 

=  16  kHz,  deviation  limit  of  +2  kHz. 

48 

96 

192 

384 

768 

1536 

3072 

The  indicated  maximum  frequency  is  based 

56 

112 

224 

448 

896 

1792 

3584 

64 

128 

256 

512 

1024 

2048 

upon  the  maximum  theoretical  response  that 
can  be  obtained  in  a  bandwidth  between 
deviation  limits  specified  for  the  channel.  See 
discussion  in  Annendix  3-A  for  determining 
practical  accuracy  versus  frequency  response 
tradeoffs. 

72 

144 

288 

576 

1152 

2304 

80 

160 

320 

640 

1280 

2560 

88 

176 

352 

704 

1408 

2816 

96 

192 

384 

768 

1536 

3072 

104 

208 

416 

832 

1664 

3328 

112 

224 

448 

896 

1792 

3584 

Prior  to  using  a  channel  outside  the  shaded 
area,  the  user  should  verify  the  availability  of 
range  assets  to  support  the  demodulation  of  the 
channel  selected.  Very  limited  support  is 
available  above  2  megahertz. 

120 

240 

480 

960 

1920 

3840 

128 

256 

512 

1024 

2048 

136 

272 

544 

1088 

2176 

144 

288 

576 

1152 

2304 

152 

304 

608 

1216 

2432 

160 

320 

640 

1280 

2560 

168 

336 

672 

1344 

2688 

176 

352 

704 

1408 

2816 
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Table  3-5.  Reference  Signal  Usage 

Reference  Frequencies  for  Tape  Speed  and  Flutter  Compensation 

Reference  Frequency  (kHz  +0.01%) 

960^1) 

480^1) 

240^1) 

200 

100 

50 

25 

12.5 

6.25 

_ 3.125 _ 

Note:  These  frequencies  are  for  flutter  compensation  only  and  not  for 

capstan  servo  speed  control.  In  addition,  the  240  kHz  reference  signal 
may  be  used  as  a  detranslation  frequency  in  a  constant-bandwidth  format. 


If  the  reference  signal  is  recorded  on  a  separate  tape  track,  any  of  the  listed  reference 
frequencies  may  be  used  provided  the  requirements  for  compensation  rate  of  change  are 
satisfied. 

If  the  reference  signal  is  mixed  with  the  data  signal,  consideration  must  be  given  to 
possible  problems  with  intermodulation  sum  and  difference  frequencies.  Also,  sufficient  guard 
band  must  be  allowed  between  the  reference  frequency  and  any  adjacent  data  subcarrier. 
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APPENDIX  3-A 

Use  Criteria  for  Frequency  Division  Multiplexing 


A.l.  General 

Successful  application  of  frequency  division  multiplexing  telemetry  standards  depends  on 
recognition  of  performance  limits  and  performance  tradeoffs,  which  may  be  required  in 
implementation  of  a  system.  The  use  criteria  included  in  this  appendix  are  offered  in  this  context 
as  a  guide  for  orderly  application  of  the  standards  presented  above.  It  is  the  responsibility  of  the 
telemetry  system  designer  to  select  the  range  of  performance  that  will  meet  data  measurement 
requirements  and  at  the  same  time  permit  operation  within  the  limits  of  the  standards.  A 
designer  or  user  must  also  recognize  the  fact  that  even  though  the  standards  for  FM/FM 
multiplexing  encompass  a  broad  range  of  performance  limits,  tradeoffs  such  as  data  accuracy  for 
data  bandwidth  may  be  necessary.  Nominal  values  for  such  parameters  as  frequency  response 
and  rise  time  are  listed  to  indicate  the  majority  of  expected  use  and  should  not  be  interpreted  as 
inflexible  operational  limits.  It  must  be  remembered  that  system  performance  is  influenced  by 
other  considerations  such  as  hardware  performance  capabilities.  In  summary,  the  scope  of  the 
standards  together  with  the  use  criteria  is  intended  to  offer  flexibility  of  operation  and  yet 
provide  realistic  limits. 

A.2.  FM  Subcarrier  Performance 

The  nominal  and  maximum  frequency  response  of  the  subcarrier  channels  listed  in  Table 
3-1,  Table  3-2,  Table  3-3,  and  Table  3-4  is  10  and  50  percent  of  the  maximum  allowable 
deviation  bandwidth.  The  nominal  frequency  response  of  the  channels  employs  a  deviation  ratio 
of  five.  The  deviation  ratio  of  a  channel  is  one-half  the  defined  deviation  bandwidth  divided  by 
the  cutoff  frequency  of  the  discriminator  output  filter. 

The  use  of  other  deviation  ratios  for  any  of  the  subcarrier  channels  listed  may  be  selected 
by  the  range  users  to  conform  to  the  specific  data  response  requirements  for  the  channel.  As  a 
rule,  the  root  mean  square  (rms)  signal-to-noise  ratio  (SNR)  of  a  specific  channel  varies  as  the 
three-halves  power  of  that  subcarrier  deviation  ratio. 

The  nominal  and  minimum  channel  rise  times  indicated  in  the  tables  listed  above  have 
been  determined  from  the  equation  which  states  that  rise  time  is  equal  to  0.35  divided  by  the 
frequency  response  for  the  nominal  and  maximum  frequency  response.  The  equation  is  normally 
employed  to  define  10  to  90  percent  rise  time  for  a  step  function  of  the  channel  input  signal; 
however,  deviations  from  these  values  may  be  encountered  because  of  variations  in  subcarrier 
components  in  the  system. 

A.3.  FM  Subcarrier  Performance  Tradeoffs 

The  number  of  subcarrier  channels  that  may  be  used  simultaneously  to  modulate  an  RF 
carrier  is  limited  by  the  RF  channel  bandwidth  and  by  the  output  SNR  that  is  acceptable  for  the 
application  at  hand.  As  channels  are  added,  it  is  necessary  to  reduce  the  transmitter  deviation 
allowed  for  each  individual  channel  to  keep  the  overall  multiplex  with  the  RF  channel 
assignment.  This  reduction  lowers  the  subcarrier-to-noise  performance  at  the  discriminator 
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inputs.  Thus,  the  system  designer's  problem  is  to  determine  acceptable  tradeoffs  between  the 
number  of  subcarrier  channels  and  acceptable  subcarrier-to-noise  ratios. 

Background  information  relating  to  the  level  of  performance  and  the  tradeoffs  that  may 
be  made  is  included  in  Telemetry  FM/FM  Baseband  Structure  Study,  volumes  I  and  II which 
were  completed  under  a  contract  administered  by  the  Telemetry  Working  Group  of  the  Inter- 
Range  Instrumentation  Group  in  1965.  The  results  of  the  study  show  that  proportional 
bandwidth  channels  with  center  frequencies  up  to  165  kilohertz  (kHz)  and  constant  bandwidth 
channels  with  center  frequencies  up  to  176  kHz  may  be  used  within  the  constraints  of  these 
standards.  The  test  criteria  included  the  adjustment  of  the  system  components  for  approximately 
equal  SNRs  at  all  of  the  discriminator  outputs  with  the  receiver  input  near  RF  threshold. 
Intermodulation,  caused  by  the  radio-link  components  carrying  the  composite  multiplex  signal, 
limits  the  channel's  performance  under  large  signal  conditions. 

With  subcarrier  deviation  ratios  of  four,  channel  data  errors  on  the  order  of  2  percent  rms 
were  observed.  Data  channel  errors  on  the  order  of  5  percent  rms  of  full-scale  bandwidth  were 
observed  when  subcarrier  deviation  ratios  of  two  were  employed.  When  deviation  ratios  of  one 
were  used,  it  was  observed  that  channel-data  errors  exceeded  5  percent.  Some  channels  showed 
peak-to-peak  errors  as  high  as  30  percent.  It  must  be  emphasized,  however,  that  the  results  of  the 
tests  performed  in  this  study  are  based  on  specific  methods  of  measurement  on  one  system 
sample  and  that  this  system  sample  represents  a  unique  configuration  of  components.  Systems 
having  different  performance  characteristics  may  not  yield  the  same  system  performance. 

System  performance  may  be  improved,  in  terms  of  better  data  accuracy,  by  sacrificing 
system  data  bandwidth;  that  is,  if  the  user  is  willing  to  limit  the  number  of  subcarrier  channels  in 
the  multiplex,  particularly  the  higher  frequency  channels,  the  input  level  to  the  transmitter  can  be 
increased.  The  SNR  of  each  subcarrier  is  then  improved  through  the  increased  per-channel 
transmitter  deviation.  For  example,  the  baseband  structure  study  indicated  that  when  the  165- 
kHz  channel  and  the  93-kHz  channel  were  not  included  in  the  proportional-bandwidth  multiplex, 
performance  improvement  can  be  expected  in  the  remaining  channels  equivalent  to 
approximately  12  decibels  (dB)  increased  transmitter  power. 

Likewise,  elimination  of  the  five  highest  frequency  channels  in  the  constant  bandwidth 
multiplex  allowed  a  6-dB  increase  in  performance. 

A  general  formula,^  which  can  be  used  to  estimate  the  thermal  noise  performance  of  an 
FM/FM  channel  above  threshold,  is  as  follows: 


f  s'^ 

r  ni/2 

(  f  ^ 

J  dc 

ff  ^ 

J  ds 

Ui 

UJ 

_B'ud  _ 

[fs  J 

V  ud  J 

Eqn.  B-1 

'  Campbell,  E.  B.  and  W.  R.  Hubert.  Telemetry  FM/FM  Baseband  Structure  Study.  2  vols.  14  June  1965. 
Available  at  http://www.dtic.mil/dtic/tr/fulltext/u2/621 139.pdf  and  http://www.dtic.mil/get-tr- 
doc/pdf?AD=AD0621 140. 

^  K.  M.  Uglow.  Noise  and  Bandwidth  in  FM/FM  Radio  Telemetry,  “IRE  Transaction  on  Telemetry  and  Remote 
Control,”  (May  1957)  pp  19-22. 
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f-1 

where  =  discriminator  output  signal-to-noise  ratio  (rms  voltage  ratio) 

(-] 

^  c  =  receiver  carrier-to-noise  ratio  (rms  voltage  ratio) 

Be  =  carrier  bandwidth  (receiver  intermediate  frequency  bandwidth) 
Fud  =  subcarrier  discriminator  output  filter:  3-dB  frequency 
fs  =  subcarrier  center  frequency 

fdc  =  carrier  peak  deviation  of  the  particular  subcarrier  of  interest 
fds  =  subcarrier  peak  deviation 


If  the  RF  carrier  power  is  such  that  the  thermal  noise  is  greater  than  the  intermodulation 
noise,  the  above  relation  provides  estimates  accurate  to  within  a  few  decibels.  Additional 
information  is  contained  in  RCC  Document  119,  Telemetry  Applications  Handbook.^ 

The  FM/FM  composite-multiplex  signal  used  to  modulate  the  RF  carrier  may  be  a 
proportional-bandwidth  format,  a  constant-bandwidth  format,  or  a  combination  of  the  two  types 
provided  only  that  guard  bands  allowed  for  channels  used  in  a  mixed  format  be  equal  to  or 
greater  than  the  guard  band  allowed  for  the  same  channel  in  an  unmixed  format. 

A.4.  FM  System  Component  Considerations 

System  performance  is  dependent  on  all  components  in  the  system.  Neglecting  the 
effects  of  the  RF  and  recording  system,  data  channel  accuracy  is  primarily  a  function  of  the 
linearity  and  frequency  response  of  the  subcarrier  oscillators  and  discriminators  employed. 
Systems  designed  to  transmit  data  frequencies  up  to  the  nominal  frequency  responses  shown  in 
Table  3-1,  Table  3-2,  Table  3-3,  and  Table  3-4  have  generally  well-known  response  capabilities, 
and  reasonable  data  accuracy  estimates  can  be  easily  made.  For  data-channel  requirements 
approaching  the  maximum  frequency  response  shown  in  the  tables  listed  above,  oscillator  and 
discriminator  characteristics  are  less  consistent  and  less  well-defined,  making  data  accuracy 
estimates  less  dependable. 

The  effect  of  the  RF  system  on  data  accuracy  is  primarily  in  the  form  of  noise  because  of 
intermodulation  at  high  RF  signal  conditions  well  above  threshold.  Under  low  RF  signal 
conditions,  noise  on  the  data  channels  is  increased  because  of  the  degraded  SNR  existing  in  the 
receiver. 

Intermodulation  of  the  subcarriers  in  a  system  is  caused  by  characteristics  such  as 
amplitude  and  phase  nonlinearities  of  the  transmitter,  receiver,  magnetic  tape 
recorder/reproducer,  or  other  system  components  required  to  handle  the  multiplex  signal  under 
the  modulation  conditions  employed.  In  systems  employing  pre-emphasis  of  the  upper 
subcarriers,  the  lower  subcarriers  may  experience  intermodulation  interference  because  of  the 
difference  frequencies  of  the  high-frequency  and  high-amplitude  channels. 


^  Range  Commanders  Council.  Telemetry  Applications  Handbook.  RCC  119-06.  May  2006.  May  be  superseded 
by  update.  Retrieved  3  June  2015.  Available  at  http://www.wsmr.armv.mil/RCCsite/Documents/119- 
06  Telemetry  Applications  Handbook/. 
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The  use  of  magnetic  tape  recorders  for  recording  a  subcarrier  multiplex  may  degrade  the 
data  channel  accuracy  because  of  the  tape  speed  differences  or  variations  between  record  and 
playback.  These  speed  errors  can  normally  be  compensated  for  in  present  discriminator  systems 
when  the  nominal  response  rating  of  the  channels  is  employed  and  a  reference  frequency  is 
recorded  with  the  subcarrier  multiplex. 

A.5.  Range  Capability  for  FM  Subcarrier  Systems 

The  following  subparagraphs  outline  additional  range  capabilities. 

A. 5. a.  Receivers  and  Tape  Recorders. 

The  use  of  subcarrier  frequencies  greater  than  2  megahertz  may  require  tape  recorders  of 
a  greater  capability  than  are  in  current  use  at  some  ranges.  It  is  recommended  that  users,  who 
anticipate  employing  any  of  the  above  channels  at  a  range,  check  the  range's  capability  at  a 
sufficiently  early  date  to  allow  procurement  of  necessary  equipment. 

A.5.b.  Discriminator  Channel  Selection  Filters. 

Inclusion  of  the  higher  frequency  proportional-bandwidth  channels  and  the  constant- 
bandwidth  channels  may  require  the  ranges  to  acquire  additional  band  selection  filters.  In 
addition  to  referencing  Table  3-1,  Table  3-2,  Table  3-3,  and  Table  3-4  for  acquiring  channel- 
selector  filters,  consideration  should  also  be  given  to  acquiring  discriminators  corresponding  to 
the  predetection  carrier  frequencies  shown  in  Annex  A. 2,  Table  A. 2-9.  In  applications  where 
minimum  time  delay  variation  within  the  filter  is  important,  such  as  tape  speed  compensation  or 
high-rate  pulse  amplitude  modulation  or  pulse  code  modulation,  constant-delay  filter  designs  are 
recommended. 
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BCD 

binary  coded  decimal 

BEP 

bit  error  probability 

Bi(^ 

bi-phase 

BifL 

bi-phase-level 

BifM 

bi-phase-mark 

BifS 

bi-phase-space 

CRC 

cyclic  redundancy  check 

dB 

decibel 

FFI 

frame  format  identifier 

FM 

frequency  modulation 

IF 

intermediate-frequency 

Isb 

least  significant  bit 

Mbps 

megabit  per  second 

msb 

most  significant  bit 

NRZ-F 

non-retum-to-zero-level 

NRZ-M 

non-retum-to-zero-mark 

NRZ-S 

non-retum-to-zero-space 

PCM 

pulse  code  modulation 

RF 

radio  frequency 

RNRZ-F 

randomized  non-return-to-zero-level 

SFID 

subframe  identifier 

SNR 

signal-to-noise  ratio 

4-iii 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  4,  July  2017 

This  page  intentionally  left  blank. 


4-iv 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  4,  July  2017 


CHAPTER  4 

Pulse  Code  Modulation  Standards 


4.1  General 

Pulse  code  modulation  (PCM)  data  are  transmitted  as  a  serial  bit  stream  of  binary-coded 
time-division  multiplexed  words.  When  PCM  is  transmitted,  premodulation  filtering  shall  be 
used  to  confine  the  radiated  radio  frequency  (RF)  spectrum  in  accordance  with  Chapter  2 
Appendix  2-A.  These  standards  define  pulse  train  structure  and  system  design  characteristics  for 
the  implementation  of  PCM  telemetry  formats.  Additional  information  and  recommendations 
are  provided  in  Appendix  4- A  and  in  RCC  1 19-06.  ^ 

4.2  Class  Distinctions  and  Bit-Oriented  Characteristics 

The  PCM  formats  are  divided  into  two  classes  for  reference.  Serial  bit  stream 
characteristics  are  described  below  prior  to  frame  and  word  oriented  definitions. 

4.2.1  Class  I  and  Class  II  Distinctions 

Two  classes  of  PCM  formats  are  covered  in  this  chapter:  the  basic,  simpler  types  are 
Class  I,  and  the  more  complex  applications  are  Class  II.  The  use  of  any  Class  II  technique 
requires  concurrence  of  the  range  involved.  All  formats  with  characteristics  described  in  these 
standards  are  Class  I  except  those  identified  as  Class  II.  The  following  are  examples  of  Class  II 
characteristics. 

a.  Bit  rates  greater  than  10  megabits  per  second  (Mbps)  (Subsection  4.2.2  item  c). 

b.  Word  lengths  in  excess  of  32  bits  (Subsection  4.3.1  item  a). 

c.  Fragmented  words  (Subsection  4.3.1  item  b). 

d.  More  than  8192  bits  or  1024  words  per  minor  frame  (Subsection  4.3.2  item  a(l)). 

e.  Uneven  spacing,  not  within  the  definition  of  subcommutation  (Subsection  4.3.2  item  c)  or 
supercommutation  (Subsection  4.3.2  item  d). 

f.  Format  changes  (Section  4.4). 

g.  Asynchronous  embedded  formats  (Paragraph  4.5). 

h.  Tagged  data  formats  (Section  4.6). 

i.  Formats  with  data  content  other  than  unsigned  straight  binary,  discretes,  or  complement 
arithmetic  representation  for  negative  numbers  such  as  floating  point  variables,  binary- 
coded  decimal,  and  gain-and-value. 

j.  Asynchronous  data  transmission  (Section  4.8). 

k.  Merger  of  multiple  format  types  (such  as  those  specified  in  Chapter  8). 


'  Range  Commanders  Council.  Telemetry  Applications  Handbook.  RCC  119-06.  May  2006.  May  be  superseded 
by  update.  Retrieved  4  June  2015.  Available  at  http://www.wsmr.armv.mil/RCCsite/Documents/119- 
06  Telemetry  Applications  Handbook/. 
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l.  Use  of  a  cyclic  redundancy  check  (CRC)  word  (Subsection  433). 

m.  Use  of  fill  bits  (Subsection  4.3.2  item  a). 

n.  Use  of  non-fixed  frame  synchronization  patterns. 


NOTE^ 

The  use  of  fixed  frame  formats  has  been  a  common  practice  but 

does  not  fit  all  requirements.  A  verification  of  range  capabilities 

should  be  made  prior  to  incorporation  of  Class  II  features  into  a 

telemetry  system. 

4.2.2  Bit-Oriented  Definitions  and  Requirements 

Definitions  and  requirements  relating  to  serial  PCM  bit  streams  are  described  next. 

a.  Binary  Bit  Representation.  The  following  code  conventions  for  representing  serial  binary 
ones  and  zeros  are  the  only  permissible  representations.  Graphic  and  written  descriptions 
of  these  conventions  are  shown  in  Figure  4-1.  Only  one  convention  shall  be  used  within 
a  single  PCM  bit  stream.  If  randomized  non-return-to-zero-level  (RNRZ-L)  is 
transmitted,  it  shall  use  the  15-bit  regeneration  pattern  as  described  in  Annex  A. 2. 

(1)  Non-retum-to-zero-level  (NRZ-L) 

(2)  Non-retum-to-zero-mark  (NRZ-M) 

(3)  Non-retum-to-zero-space  (NRZ-S) 

(4)  Bi-phase-level  (Bi(j)-L) 

(5)  Bi-phase-mark  (Bi(j)-M) 

(6)  Bi-phase-space  (Bi(t)-S) 
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LOGIC 
CODE  level 


CODE  WAVEFORM 


LOGIC 

LEVEL  CODE  DESCRIPTION 


1 

NRZ-L 

0 


1 

NRZ-M 

0 


1 

NRZ-S 

0 


1 

Bi<P-L 

0 


1 
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0 


1 
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1  I 


rv 


1  I 


1  I  0  I  0  I  0 
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<  n  I 
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vixinni 


"T — '  r 

I  I 
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AJJn 


1  I 


1  I 


71/1/1/ 


1  I  0 

71/ 


\I\j 


1  I 


nx 


r\i\i 


inj^ 


Non-Return^TchZero  -  Level  (NRZ-L) 

-  1  “ONE"  is  represented  by  one  level 

-  0  “ZERO"  is  represented  by  the  other  level 


Non-Retum-To-Zero  -  Mark  (NRZ-M) 

-  1  “ONE"  is  represented  by  a  change  in  level 

-  0  “ZERO"  is  represented  by  NO  change  in  level 


Non-Return-To-Zero  -  Level  (NRZ-S) 

-  1  “ONE"  is  represented  by  NO  change  in  level 

-  0  “ZERO"  is  represented  by  a  change  in  level 


Bi-Phase- Level  (Bi0-L) 

“ONE"  is  represented  by  a  "ONE"  level  with 
transition  to  the  "ZERO"  level 

_  Q  "ZERO"  is  represented  by  a  “ZERO"  level  with 

transition  to  the  “ONE"  level 


Bi-Phase  -  Mark  (Bi0-M) 

“ONE"  is  represented  by  NO  level  change  at  the 
beginning  of  the  bit  period 

_ Q  “ZERO"  is  represented  by  a  level  change  at  the 

beginning  of  tfie  bit  period 


Bi-Phase  -  Space  (Bi0’S) 

“ONE"  is  represented  by  a  level  change  at  the 
^  beginning  of  the  bit  period 

_ Q  “ZERO"  is  represented  by  a  NO  level  change  at 

the  beginning  of  the  bit  period 


Note:  (1 )  The  Bi<t>  codes  may  be  derived  from  the  corresponding  NRZ  codes  by  inverting  the  level  for  the  last  half  of  each  bit  interval. 


Figure  4-1.  PCM  Code  Definitions 
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b.  Serial  Bit  Stream  Transitions.  The  transmitted  or  recorded  bit  stream  shall  be  continuous 
and  shall  contain  sufficient  transitions  to  ensure  bit  acquisition  and  continued  bit 
synchronization,  taking  into  account  the  binary  representation  chosen.  See  the 
recommendation  in  Section  A.3. 

c.  Bit  Rate.  The  RF  and  recording  limits,  defined  in  Chapter  2  and  Chapter  6,  should  be 
considered  when  determining  maximum  bit  rates.  The  minimum  bit  rate  shall  be  10  bits 
per  second.  Bit  rates  greater  than  10  Mbps  are  Class  II. 

d.  Bit  Rate  Accuracy  and  Stability.  During  any  period  of  desired  data,  the  bit  rate  shall  not 
differ  from  the  specified  nominal  bit  rate  by  more  than  0. 1  percent  of  the  nominal  rate. 

e.  Bit  Jitter.  The  bit  jitter  shall  not  exceed  +0.1  of  a  bit  interval  referenced  to  the  expected 
transition  time  with  no  jitter.  The  expected  transition  time  shall  be  based  on  the 
measured  average  bit  period  as  determined  during  the  immediately  preceding  1000  bits. 

4.2.3  Bit  Clocking  Definitions  and  Requirements 

Clock  phase  is  defined  in  relationship  to  data  transition.  Graphic  and  written  descriptions 
of  following  conventions  are  shown  in  Figure  4-2. 


data 

0  degree  clock: 
data  valid  on  falling  edge 

90  degree  clock: 
data  valid  in  middle 
of  high  clock 

180  degree  clock: 
data  valid  on  rising  edge 

270  degree  clock: 
data  valid  in  middle 
of  low  clock 

double-data  rate  clock: 
data  valid  on  both  rising 
and  falling  clock  edges 


\±J 


\ 


I  I  III 


f 


data  valid 


data  transition 


Figure  4-2.  PCM  Clock  Definitions 


a.  0°  clock.  Data  transitions  on  the  rising  edge  of  the  clock.  Data  is  valid  on  the  falling 
edge  of  the  clock. 

a.  90°  clock.  Data  transitions  in  the  middle  of  clock  low.  Data  is  valid  in  the  middle  of 
clock  high. 

b.  180°  clock.  Data  transitions  on  the  falling  edge  of  the  clock.  Data  is  valid  on  the  rising 
edge  of  the  clock. 
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c.  270°  clock.  Data  transitions  in  the  middle  of  clock  high.  Data  is  valid  in  the  middle  of 
clock  low. 

d.  Double-data  rate  clock.  Also  known  as  half  clock.  Data  transitions  in  the  middle  of  both 
clock  high  and  low.  Data  is  valid  on  both  rising  and  falling  edge  of  clock. 

4.3  Fixed  Formats 

Characteristics  of  fixed  formats  are  described  below.  Fixed  formats  do  not  have  changes 
during  transmission  with  regard  to  frame  structure,  word  length  or  location,  commutation 
sequence,  sample  interval,  or  measurement  list. 

4.3.1  Word-Oriented  Definitions  and  Requirements 

The  following  definitions  and  requirements  are  addressed  to  word  characteristics. 

a.  Word  Length  (Class  I  and  II).  Individual  words  may  vary  in  length  from  4  bits  to  not 
more  than  32  bits  in  Class  I  and  not  more  than  64  bits  in  Class  II. 

b.  Fragmented  Words  (Class  I  and  II).  A  fragmented  word  is  defined  as  a  word  divided  into 
no  more  than  eight  segments  and  placed  in  various  locations  within  a  minor  frame. 
Locations  need  not  be  adjacent.  For  Class  I,  all  word  segments  used  to  form  a  data  word 
shall  be  constrained  to  the  boundaries  of  a  single  minor  frame.  Class  II  may  fragment 
across  minor  frames,  though  this  is  not  recommended.  Fragmented  synchronization 
words  are  not  allowed. 

c.  Bit  Numbering.  To  provide  consistent  notation,  the  most  significant  bit  (msb)  in  a  word 
shall  be  numbered  “one”.  Less  significant  bits  shall  be  numbered  sequentially  within  the 
word. 

d.  Word  Numbering.  To  provide  consistent  notation,  the  minor  frame  synchronization 
pattern  word  shall  be  numbered  “zero”  and  the  first  word  after  the  minor  frame 
synchronization  pattern  shall  be  numbered  “one”  (see  Figure  4-3).  Each  subsequent  word 
shall  be  sequentially  numbered  within  the  minor  frame.  Numbering  within  a  subframe 
(see  Subsection  4.3.2  item  c(l))  shall  be  “one”  for  the  word  in  the  same  minor  frame  as 
the  initial  counter  value  for  subframe  synchronization  and  sequentially  thereafter. 
Notations  of  W  and  S  shall  mean  the  W  word  position  in  the  minor  frame  and  S  word 
position  in  the  subframe. 
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Minor  Frame  Length  “N”  Words  of  “B”  Bits 

_  Max  Length:  _ 

CLASS  1-8192  Bits  or  1024  Words 
CLASS  II  -  16,384  Bits 

Major  Frame  consisting  of  Y  minor  frames 


•  The  minor  frame  sync  is  considered  one  word. 

-  Independent  of  the  length  of  the  minor  frame  sync. 

-  Is  always  numbered  0. 

•  By  definition  a  major  frame  contains  N*Y  words  or  B*Y  bits. 

-  N  is  the  number  of  words  in  one  minor  frame. 

-  B  is  the  number  of  bits  in  one  minor  frame. 

-  W  is  a  word  position  in  the  minor  frame  of  a  subframe  that  uses  SFID1 . 

-  S  is  a  word  position  in  the  subframe  that  uses  SFID1 . 

-  X  is  a  word  position  in  the  minor  frame  of  a  subframe  that  uses  SFID2. 

-  Y  is  the  number  of  distinct  values  of  SFID1  (max  256). 

-  Z  is  the  number  of  distinct  values  of  SFID2,  in  this  example  it  is  less  than  Y,  but 

may  be  of  any  value.  The  largest  of  these  two  defines  minor  frames  per  major 
frame 

•  The  Subframe  ID  Counters  (SFID1,  SFID2) 

-  Can  occupy  any  fixed  word  position  after  the  minor  frame  sync 

-  Can  have  a  min  count  of  0  or  1 . 

-  Can  increment  or  decrement  by  1 . 

Figure  4-3.  PCM  Frame  Structure 


4.3.2  Frame  Structure 

The  PCM  data  shall  be  formatted  into  fixed  length  frames  as  defined  in  these  sections 
regarding  frame  structure  and  in  Figure  4-3.  Frames  shall  contain  a  fixed  number  of  equal 
duration  bit  intervals. 

a.  Minor  Frame.  The  minor  frame  is  defined  as  the  data  structure  in  time  sequence  from  the 
beginning  of  a  minor  frame  synchronization  pattern  to  the  beginning  of  the  next  minor 
frame  synchronization  pattern.  Certain  Class  II  PCM  systems  may  insert  a  variable 
number  of  fill  bits  between  the  end  of  one  minor  frame  and  the  synchronization  pattern  of 
the  next  minor  frame.  When  this  is  done,  these  filler  bits  are  not  considered  to  be  a  part 
of  either  minor  frame. 
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(1)  Minor  Frame  Length  (Class  I  and  II).  The  minor  frame  length  is  the  number  of  bit 
intervals  from  the  beginning  of  the  frame  synchronization  pattern  to  the  beginning 
of  the  next  synchronization  pattern.  The  maximum  length  of  a  minor  frame  shall 
exceed  neither  8192  bits  nor  1024  words  in  Class  I  and  shall  not  exceed  16384  bits 
in  Class  II.  If  fill  bits  are  inserted,  they  are  not  to  be  used  in  the  calculation  of  the 
minor  frame  length. 

(2)  Minor  Frame  Composition.  The  minor  frame  shall  contain  the  minor  frame 
synchronization  pattern,  data  words,  and  subframe  synchronization  words,  if  used. 
Words  of  different  length  may  be  multiplexed  in  a  single  minor  frame.  The  length 
of  a  word  in  any  identified  word  position  within  a  minor  frame  shall  be  constant. 
Other  words  such  as  frame  format  identifiers  (FFIs)  may  be  needed  within  Class  II 
formats  (see  Section  4.4). 

(3)  Minor  Frame  Synchronization.  The  minor  frame  synchronization  information  shall 
consist  of  a  fixed  digital  word  not  longer  than  33  consecutive  bits  and  not  shorter 
than  16  bits.  The  minor  frame  synchronization  pattern  is  always  considered  as  one 
word,  regardless  of  its  length.  Recommended  synchronization  patterns  are  given  in 
Table  A-1.  Class  II  formats  may  use  an  alternating  complement  synchronization 
pattern  that  complements  after  each  minor  frame. 

(4)  Transmitted  Frame  Counter.  The  frame  counter  provides  a  natural  binary  count 
corresponding  to  the  minor  frame  number  in  which  the  frame  count  word  appears. 

It  is  recommended  that  such  a  counter  be  included  in  all  minor  frames  whether 
Class  I  or  Class  II  and  is  especially  desirable  in  Class  II  formats  to  assist  with  data 
processing.  The  frame  counter  should  be  of  nominal  format  word  length  and  reset 
to  start  up-counting  again  after  reaching  maximum  value.  In  formats  where 
subcommutation  is  present,  the  subframe  identifier  (SFID)  counter  may  serve  as  the 
frame  counter. 

(5)  Bit  Numbering  in  a  Minor  Frame.  To  provide  consistent  notation,  the  first  bit  in  a 
minor  frame  (the  first  bit  in  the  sync  pattern)  shall  be  numbered  “one”.  Each 
subsequent  bit  shall  be  sequentially  numbered  within  the  minor  frame.  This  is  used 
forCRC. 

b.  Major  Frame.  A  major  frame  contains  the  number  of  minor  frames  required  to  include 
one  occurrence  of  every  word  in  the  format.  See  Figure  4-3. 

(1)  Major  Frame  Length.  Major  frame  length  is  defined  as  minor  frame  length  (N 
words  or  B  bits)  multiplied  by  the  number  of  minor  frames  (Z)  in  the  major  frame. 
The  maximum  number  of  minor  frames  per  major  frame  shall  not  exceed  256. 

(2)  Minor  Frame  Numbering.  To  provide  consistent  notation,  the  first  minor  frame  in  a 
major  frame  shall  be  numbered  “one”.  Each  subsequent  minor  frame  shall  be 
numbered  sequentially  within  the  major  frame. 

c.  S ubcommutation .  Subcommutation  is  defined  as  a  sampling  of  parameters  at  submultiple 
rates  (1/D)  of  the  minor  frame  rate  where  the  depth  of  a  subframe,  D,  is  an  integer  in  the 
range  of  2  to  Z. 
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(1)  Subframe.  Subframe  is  defined  as  one  cycle  of  the  parameters  from  a 
subcommutated  minor  frame  word  position.  The  depth,  D,  of  a  subframe  is  the 
number  of  minor  frames  in  one  cycle  before  repetition. 

(2)  Subframe  Synchronization  Method.  The  standard  method  for  subframe 
synchronization  is  to  use  a  SFID  counter,  a  binary  counter  that  counts  sequentially 
up  or  down  at  the  minor  frame  rate.  Typically,  only  one  SFID  counter  is  used  in  a 
PCM  format;  however,  more  than  one  counter  may  be  used  if  needed.  This 
paragraph  assumes  the  use  of  one  SFID  counter.  The  SFID  counter  shall  be  located 
in  a  fixed  position  in  each  and  every  minor  frame.  The  counter  should  start  with  the 
minimum  counter  value  when  counting  up  or  the  maximum  counter  value  when 
counting  down.  The  counter  should  also  be  left  or  right  justified  in  a  word  position. 
The  start  of  a  major  frame  shall  coincide  with  the  initial  count  for  the  deepest 
subframe. 

(3)  SFID  Counter  Location.  The  SFID  counter  should  be  placed  in  the  minor  frame 
prior  to  any  subcommutated  parameters.  Subcommutated  parameters  that  occur  in 
the  minor  frame  prior  to  the  SFID  counter  are  undefined. 

d.  Supercommutation.  Supercommutation  is  defined  as  time-division-multiplex  sampling  at 
a  rate  that  is  a  multiple  of  the  minor  frame  rate.  Supercommutation  (on  a  minor  frame) 
provides  multiple  samples  of  the  same  parameter  in  each  minor  frame. 

Supercommutation  on  a  subframe  is  defined  as  time-division-multiplex  sampling  at  a  rate 
that  is  a  multiple  of  the  subframe  rate  and  provides  multiple  samples  of  the  same 
parameter  within  a  subframe.  For  Class  I,  supercommutated  samples  shall  be  evenly 
spaced.  For  Class  II,  supercommutated  samples  should  be  as  evenly  spaced  as  practical. 

4.3.3  Cyclic  Redundancy  Check  (Class  II) 

A  CRC  is  an  error-detecting  code  commonly  used  in  digital  networks  and  storage 
devices.  It  can  detect  strings  of  bit  errors  that  are  of  the  length  of  the  CRC  check  word.  If  a 
CRC  check  word  is  to  be  used,  it  should  be  inserted  at  the  end  of  each  minor  frame  and  occupy 
the  same  location  in  each  minor  frame.  It  shall  not  occupy  any  bits  from  the  frame  sync  pattern. 
It  shall  occupy  contiguous  bits,  but  may  cross  word  boundaries.  The  CRC  check  word  shall 
always  be  inserted  msb  first. 

The  CRC  shall  be  calculated  in  bit-transmit  order.  The  maximum  length  of  bits  to  be 
checked  shall  be  the  length  of  one  minor  frame,  but  the  bits  being  checked  may  span  two  minor 
frames.  Minor  frame  fill  bits  shall  not  be  used  as  part  of  a  CRC  calculation.  The  CRC 
calculation  shall  not  use  pre-inversion,  post-inversion,  reversed  bit  ordering,  unusual  starting 
value,  or  final  XOR.  Since  ground  station  software  typically  runs  in  a  general  purpose  computer, 
the  decoding  of  the  CRC  will  usually  be  done  in  software.  Therefore,  only  a  subset  of  16  and  32 
bit  CRCs  shall  be  supported.  The  supported  CRC  polynomials  are  as  follows: 

CRC- 1 6- ANSI:  x^^  +  x^^  +  x^+ I 

CRC- 1 6-CCITT:  x^^  +  x^^  +  x^  +  I 

CRC-32:  x?^  +  x^^  +  x^^+x^^  +  x^^  +  x^^  +  x^^+x^^  +  x^  +  x^  +  xf  +  x^  +  x^  +  x+\ 
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4.4  Format  Change  (Class  II) 

Format  change  is  defined  as  change  with  regard  to  frame  structure,  word  length  or 
location,  commutation  sequence,  sample  interval,  or  change  in  measurement  list.  Format 
changes  shall  occur  only  on  minor  frame  boundaries.  Bit  synchronization  shall  be  maintained 
and  fill  bits  used  instead  of  intentional  dead  periods.  Format  changes  are  inherently  disruptive  to 
test  data  processing;  fixed  format  methods  are  preferred.  Format  change  methods  shall  conform 
to  the  characteristics  described  in  the  following  sections. 

4.4.1  Frame  Format  Identification 

An  FFI  is  a  word  that  shall  uniquely  identify  a  single  format.  In  formats  where  change  is 
required,  the  FFI  shall  be  placed  in  every  minor  frame.  The  format  identifier  shall  be  the  same 
length  as  (or  multiples  of)  the  most  common  word  length  in  the  format  and  shall  occur  in  a  fixed 
position  in  the  minor  frame.  The  FFI  shall  identify  the  format  applicable  to  the  current  minor 
frame.  Frame  synchronization  pattern,  FFI  location,  bit  rate,  and  binary  bit  representation  code 
shall  not  be  changed.  The  FFI  shall  be  constructed  such  that  a  single  bit  error  cannot  produce 
another  valid  FFI.  The  number  of  unique  formats  indicated  shall  not  exceed  16. 

4.4.2  Format  Change  Implementation  Methods 

The  following  subparagraphs  describe  format  change  implementation  methods. 

a.  Measurement  List  Change.  This  method  of  format  change  consists  of  a  modification  in 
data  content  only  and  not  format  structure. 

b.  Format  Structure  Change.  Defined  as  a  format  change  where  there  is  a  departure  in 
frame  structure  and  not  just  data  content. 

4.5  Asynchronous  Embedded  Format  (Class  II) 

An  asynchronous  embedded  format  is  defined  as  a  secondary  data  stream  asynchronously 
embedded  into  a  host  major  frame  in  a  manner  that  does  not  allow  predicting  the  location  of 
embedded  synchronization  information  based  only  on  host  format  timing.  It  is  recommended 
that  the  embedded  frame  segments  be  inserted  as  an  integral  number  of  words  in  every  host 
minor  frame,  so  that  in  the  combined  format,  specific  word  positions  in  the  host  minor  frame  are 
dedicated  to  the  embedded  asynchronous  format;  however,  placing  the  asynchronous  embedded 
format  only  in  selected  host  minor  frames  is  permitted.  It  is  also  recommended  that  no  more 
than  two  asynchronous  embedded  formats  be  inserted  in  a  host  major  frame,  but  more  than  two 
are  permitted. 

4.6  Tagged  Data  Format  (Class  II) 

A  tagged  data  format  is  defined  as  a  fixed  frame  length  format  having  no  applicable 
subframe  or  major  frame  definitions  and  characterized  as  a  stream  of  data  words,  or  blocks  of 
words,  with  associated  identifiers  (tags).  These  formats  consist  of  frame  synchronization 
patterns,  identifiers,  data  words,  and  fill  words  as  required. 

4.6.1  Alternating  Tag  and  Data 

This  tagged  data  format  consists  of  frames  containing  tag  words  alternating  in  time 
sequence  with  data  words  or  blocks  of  words  identified  by  the  tags. 
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4.6.2  Bus  Data.  MIL-STD  1553 

The  preferred  method  of  telemetering  MIL-STD  1553  information  is  for  the  information 
to  be  restructured  to  conform  to  Class  I  methods.  If  not  restructured,  telemetered  MIL-STD 
1553  data  shall  conform  to  Chapter  8.  This  data  format  is  described  in  Military  Standard  1553^. 

4.6.3  Bus  Data,  ARINC  429 

The  preferred  method  of  telemetering  ARINC  information  is  for  the  information  to  be 
restructured  to  conform  to  Class  I  methods.  If  not  restructured,  telemetered  ARINC  429  data 
shall  be  consistent  with  the  specification  of  ARINC  429  bus  data,  as  implemented  in  Chapter  8. 
This  data  format  is  described  in  Aeronautical  Radio,  Inc.  429^. 

4.7  Time  Words 

The  following  paragraphs  describe  the  formatting  of  time  words  within  a  PCM  stream.  A 
16-bit  standardized  time  word  format  and  a  method  to  insert  time  words  into  PCM  word  sizes 
other  than  16-bits  are  described. 

In  16-bit  standardized  time  word  format,  there  shall  be  three  words  dedicated  to 
providing  timing  information.  These  words  are  designated  high  order  time,  low  order  time,  and 
microsecond  time.  High  and  low  order  time  words  shall  be  binary  or  binary  coded  decimal 
(BCD)  weighted,  and  microsecond  words  shall  be  binary  weighted.  Time  word  construction 
examples  are  shown  in  Figure  4-4  and  Figure  4-5. 


Figure  4-4.  16-Bit  Standardized  Time  Word  Format 


^  Department  of  Defense.  Aircraft  Internal  Time  Division  Command/Response  Multiplex  Data  Bus.  MIL-STD- 
1553B.  21  September  1978.  May  be  superseded  by  update.  Retrieved  4  June  2015.  Available  at 
httD://quicksearch.dla.mil/basic  profile. cfm?ident  number=36973&method=basic. 

^  Aeronautical  Radio,  Inc.  Mark  33  Digital  Information  Transfer  System  (DITS).  ARINC  429.  Annapolis:  ARINC, 
1995. 


4-10 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  4,  July  2017 


HIGH  ORDER  TIME 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

24 

,4LL  ZERO  FILLER 

(S)  idayJiohrJ 


1  HR - ^10  MIN 


(BCD) 

(Biiiaiy) 


(Binary 

Weighting) 


0  0 


1  MIN 
655.36  SEC 


LOM  ORDER  TIME 


PCM  WORD  >+2 


PCM  WORD  X+3 


0 

ALL  ZERO  FILLER 

1  SEC 


0.1  SEC- 


0.01  SEC 


0.01  SEC" 

NHC  ROSECOND  TIME 


PCM  WORD  N+4 


PCM  WORD  N+5 


ALL  ZERO  FILLER 


1  MICROSECOND 


Figure  4-5.  Time  Word  Insertion  Into  12-Bit  PCM  Word  Size 


The  microsecond  time  word  shall  have  a  resolution  of  1  microsecond;  that  is,  the  least 
significant  bit  (Isb),  bit  16,  has  a  value  of  0.000001  second.  This  word  shall  increment  until  it 
attains  a  value  of  10  milliseconds  at  which  time  it  will  reset  to  zero.  Thus  the  maximum  value  of 
the  counter  is  9999  (decimal). 

The  low  order  time  word  shall  have  a  resolution  of  10  milliseconds;  that  is,  the  Isb,  bit  16, 
of  the  low  order  time  word  shall  have  a  value  of  0.01  second. 

The  high  order  time  word  shall  have  a  resolution  of  655.36  seconds  when  binary 
weighted;  that  is,  the  Isb,  bit  16,  has  a  value  of  655.36  seconds.  When  BCD  weighted,  the  Isb, 
bit  16,  of  the  high  order  time  word  shall  have  a  value  of  one  minute.  For  BCD,  the  days  field 
shall  contain  the  three  least  significant  bits  of  the  BCD  Julian  date. 

It  is  recommended  that  high,  low,  and  microsecond  time  words  precede  the  first  data 
word  in  the  minor  frame.  The  time  word  order  shall  be  high  order  time  word,  followed  by  low 
order  time  word,  followed  by  microsecond  time  word.  Microsecond  time  words  may  be  used  to 
tag  individual  data  words,  but  care  shall  be  taken  that  high  order  and  low  order  time  words  be 
inserted  at  a  rate  necessary  to  resolve  time  ambiguities. 

Time  word  insertion  into  PCM  word  sizes  other  than  16  bits  shall  be  as  follows:  high 
order,  low  order,  and  microsecond  time  words  shall  be  inserted  into  PCM  words  with  time  word 
bits  occupying  contiguous  bit  locations  in  the  PCM  word.  The  time  word  shall  occupy 
contiguous  PCM  data  words  until  the  time  word  is  contained  in  the  PCM  stream.  If  the  time 
word  size  is  not  an  integer  multiple  of  the  PCM  word  size  and  there  are  unused  bits  in  the  PCM 
word,  the  remaining  unused  bits  in  the  last  PCM  word  that  contains  the  time  word  shall  be  fill 
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bits  with  value  0.  Figure  4-5  illustrates  the  insertion  of  time  words  into  a  PCM  stream  with  word 
size  of  12  bits. 

4.8  Asynchronous  Data  Merge  (Class  II) 

Asynchronous  data  is  defined  as  an  external  sequential  data  stream  (consisting  of  data 
bits,  associated  overhead,  and  optional  parity,  all  at  an  autonomous  update  rate)  that  is  a 
candidate  for  insertion  into  a  primary  or  “host”  PCM  format.  Common  examples  are  RS-232 
serial  and  IEEE-488  parallel  messages.  This  section  does  not  apply  to  secondary  PCM  formats 
that  are  to  be  embedded  as  described  in  Paragraph  Merger  shall  comply  with  Subsection 
4.2.2. 

Each  source  of  merged  data  shall  use  fixed  word  positions  in  the  host  format.  It  is 
recommended  that  the  merged  data  be  inserted  as  an  integral  number  of  words  in  every  host 
minor  frame,  so  that  in  the  combined  format,  specific  word  positions  in  the  host  minor  frame  are 
dedicated  to  the  merged  data  format;  however,  placing  the  merged  data  format  only  in  selected 
host  minor  frames  is  permitted.  It  is  also  recommended  that  no  more  than  two  merged  data 
formats  be  inserted  in  a  host  major  frame,  but  more  than  two  are  permitted.  The  following 
conventions  are  recommended,  but  variations  are  allowed. 

4.8.1  PCM  Data  Word  Eormat 

Eigure  4-6  illustrates  the  host  PCM  format  word  containing  a  merged  asynchronous  data 
word  and  associated  overhead,  which  is  referred  to  as  an  asynchronous  word  structure.  The  data 
may  be  inserted  in  any  length  PCM  word  that  will  accommodate  the  required  bits. 

Asynchronous  data  shall  not  be  placed  in  fragmented  words.  Multiple  host  PCM  format  words, 
if  used,  shall  be  contiguous. 


Eigure  4-6.  Asynchronous  Word  Structure 


4.8.2  Insertion  Process 

The  asynchronous  word  structure  shall  contain  the  information  from  the  asynchronous 
message  partitioned  into  two  fields,  data  and  overhead,  as  shown  in  Eigure  4-6.  The 
asynchronous  message  is  inserted  into  the  asynchronous  word  structure  with  the  following  bit 
orientations.  The  most  significant  data  bit  (msb)  through  least  significant  data  bit  (Isb)  and  parity 
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(if  used)  of  the  message  are  denoted  as  D1  (msb)  through  Di  and  will  be  inserted  into  structure 
bits  B1  (msb)  through  Bi.  The  next  two  structure  bits,  B(i-i-l)  and  B(i-i-2)  are  reserved  for  the 
stale  and  overflow  flags  generated  by  the  host  encoder.  All  remaining  overhead  (message  and 
host  encoder  generated)  D(i-i-3)  through  Dn  (Isb),  will  be  inserted  into  structure  bits  B(i-i-3) 
through  Bn  (Isb). 

a.  Transmission  Overhead.  All  transmission  overhead  not  required  for  data  reconstruction 
shall  be  removed. 

b.  Parity  Bit.  Transmission  of  a  parity  bit  is  optional.  If  it  is  transmitted,  it  shall  be  at  the 
end  of  the  data  field  (see  Figure  4-6)  adjacent  to  the  Isb  of  the  data. 

c.  Data  Bits.  The  data  bits  shall  be  inserted  into  the  PCM  word  with  the  msb  of  the 
asynchronous  data  aligned  with  the  msb  of  the  PCM  word. 

d.  Stale  Data  Bit.  A  stale  data  bit  flag  shall  be  generated  each  time  a  new  data  value  is 
inserted  into  the  PCM  stream.  The  flag  shall  be  transmitted  with  the  associated  data.  The 
flag  bit  shall  be  placed  in  the  next  less  significant  bit  location  following  the  Isb  of  the 
data.  If  new  data  is  not  ready  for  transmission  by  the  time  the  PCM  word  must  be  sent 
again,  either  the  old  data  or  alternating  one/zero  fill  shall  be  sent  and  the  flag  set.  Stale 
data  shall  be  indicated  by  a  binary  “one”  (see  Table  4-1). 


Table  4-1.  Overhead  Truth  Table 

Stale  Bit 

Overflow  Bit 

0 

0 

Fresh  Data 

0 

1 

Data  Overflow 

1 

0 

Stale  Data 

1 

1 

User  Defined 

e.  Overflow  Bit.  An  overflow  bit  flag  shall  be  generated  to  indicate  an  abnormal  condition 
in  which  data  may  be  lost.  The  overflow  bit  shall  be  placed  in  the  next  less  significant 
data  bit  location  following  the  stale  bit  flag.  An  overflow  bit  at  a  binary  “one”  indicates 
that  a  data  discontinuity  exists  between  the  current  data  word  and  the  previous  data  word 
(see  Table  4-1  above). 

f.  Insertion  Rate.  The  asynchronous  word  structure  shall  be  inserted  into  the  host  PCM 
word  at  a  rate  to  avoid  data  loss  in  the  PCM  stream. 
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APPENDIX  4-A 

Additional  Information  and  Recommendations 

A.l.  Bit  Rate  Versus  Receiver  Intermediate- Frequency  Bandwidth 

The  following  subparagraphs  contain  information  about  selection  of  receiver 
intermediate-frequency  (IF)  bandwidths.  Additional  information  is  contained  in  RCC  document 
119-06. 

The  standard  receiver  IF  bandwidth  values  are  listed  in  Chapter  2,  Table  2-1.  Not  all 
bandwidths  are  available  on  all  receivers  or  at  all  test  ranges.  Additional  bandwidths  may  be 
available  at  some  test  ranges.  The  IF  bandwidth,  for  data  receivers,  should  typically  be  selected 
so  that  90  to  99  percent  of  the  transmitted  power  spectrum  is  within  the  receiver  3-decibel  (dB) 
bandwidth. 

For  reference  purposes,  in  a  well-designed  PCM/frequency  modulation  (FM)  system 
(NRZ-L  data  code)  with  peak  deviation  equal  to  0.35  times  the  bit  rate  and  an  IF  bandwidth  (3 
dB)  equal  to  the  bit  rate,  a  receiver  IF  signal-to-noise  ratio  (SNR)  of  approximately  13  dB  will 
result  in  a  bit  error  probability  (BEP)  of  10"^.  A  1-dB  change  in  this  SNR  will  result  in 
approximately  an  order  of  magnitude  change  in  the  BEP.  The  relationship  between  BEP  and  IP 
SNR  in  a  bandwidth  equal  to  the  bit  rate  is  illustrated  in  Pigure  A-1  for  IP  bandwidths  equal  to 
the  bit  rate  and  1.5  times  the  bit  rate.  An  approximate  expression  for  the  BEP  is: 

BEP  =  0.5  Eqn.  A-1 

where:  k  w  -0.7  for  IP  bandwidth  equal  to  bit  rate 

k  «  -0.65  for  IP  bandwidth  equal  to  1.2  times  bit  rate 
k  «  -0.55  for  IP  bandwidth  equal  to  1.5  times  bit  rate 
SNR  =  IP  SNR»IP  bandwidth/bit  rate. 


+  IF  Bandwidth  =  1.5  limes  Bit  Rote 
X  IF  Bandwidth  :=  1.0  times  Bit  Rote 


Pigure  A- 1.  BEP  vs.  IP  SNR  in  Bandwidth  =  Bit  Rage  for  NRZ-P  PCM/PM 
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Other  data  codes  and  modulation  techniques  have  different  BEP  versus  SNR  performance 
characteristics. 

It  is  recommended  that  the  maximum  period  between  bit  transitions  be  64-bit  intervals  to 
ensure  adequate  bit  synchronization. 

A.2.  Recommended  PCM  Synchronization  Patterns 

Table  A-1  contains  recommended  frame  synchronization  patterns  for  general  use  in  PCM 
telemetry.  Patterns  are  shown  in  the  preferred  order  of  transmission  with  “11 1”  being  the  first 
bit  sequence  transmitted.  This  order  is  independent  of  data  being  least-significant-bit  or  most- 
significant-bit  aligned.  The  technique  used  in  the  determination  of  the  patterns  for  lengths  16 
through  30  was  essentially  that  of  the  patterns  of  2"  binary  patterns  off  a  given  length,  n,  for  that 
pattern  with  the  smallest  total  probability  of  false  synchronization  over  the  entire  pattern  overlap 
portion  of  the  ground  station  frame  synchronization."^  The  patterns  for  lengths  31  through  33 
were  obtained  from  a  second  source.^ 


Table  A-1.  Optimum  Frame  Synchronization  Patterns  for  PCM  Telemetry 

Pattern 

Length 

Patterns 

16 

ill 

010 

111 

001 

000 

0 

17 

ill 

100 

no 

101 

000 

00 

18 

ill 

100 

no 

101 

000 

000 

19 

ill 

no 

on 

001 

010 

000 

0 

20 

ill 

on 

on 

no 

001 

000 

00 

21 

ill 

on 

101 

001 

on 

000 

000 

22 

ill 

100 

no 

no 

101 

000 

000 

0 

23 

ill 

101 

on 

100 

no 

100 

000 

00 

24 

ill 

no 

101 

111 

001 

100 

100 

000 

25 

ill 

no 

010 

no 

111 

000 

100 

000 

0 

26 

ill 

no 

100 

no 

101 

100 

no 

000 

00 

27 

ill 

no 

101 

101 

001 

100 

no 

000 

000 

28 

ill 

101 

on 

no 

010 

no 

on 

000 

000 

0 

29 

ill 

101 

on 

no 

on 

001 

101 

000 

000 

00 

30 

ill 

no 

101 

111 

001 

100 

no 

100 

000 

000 

31 

ill 

111 

100 

no 

111 

no 

101 

000 

010 

000 

0 

32 

ill 

111 

100 

no 

101 

100 

101 

000 

010 

000 

00 

33 

ill 

no 

111 

010 

on 

101 

001 

010 

010 

on 

000 

A  more  detailed  account  of  this  investigation  can  be  found  in  a  paper  by  J.  L.  Maury,  Jr.  and  J.  Styles, 
“Development  of  Optimum  Frame  Synchronization  Codes  for  Goddard  Space  Flight  Center  PCM  Telemetry 
Standards.”  In  Proceedings  of  the  National  Telemetering  Conference,  June  1964. 

^  The  recommended  synchronization  patterns  for  lengths  31  through  33  are  discussed  more  fully  in  a  paper  by  E.  R. 
Hill,  “Techniques  for  Synchronizing  Pulse-Code  Modulated  Telemetry.”  In  Proceedings  of  the  National 
Telemetering  Conference,  May  1963. 
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A.3.  Spectral  and  BEP  Comparisons  for  NRZ  and  Bi-phase® 

Figure  A-2  shows  the  power  spectral  densities  of  baseband  NRZ  and  Bitj)  codes  with 
random  data.  These  curves  were  calculated  using  the  equations  presented  below.  Figure  A-3 
presents  the  theoretical  BEPs  versus  SNR  for  the  level,  mark,  and  space  versions  of  baseband 
NRZ  and  Bitj)  codes  and  also  for  RNRZ-L.  The  noise  is  assumed  to  be  additive  white  Gaussian 
noise. 

NRZ  SPECTRAL  DENSITY  a  Eqn.  A-2 

{^JTf 

Bi(l)  SPECTRAL  DENSITY  a 


$,m^{nfT  11) 
[nfTlif 


where  T  is  the  bit  period. 


NRZ 


—  Bi(t) 


Eigure  A-2.  Spectral  Densities  of  Random  NRZ  and  Bi(|)  Codes 


®  Material  presented  in  paragraph  3.0  is  taken  from  a  study  by  W.  C.  Lindsey  (University  of  Southern  California), 
Bit  Synchronization  System  Performance  Characterization,  Modeling  and  Tradeoff  Study.  AD-766974.  Naval 
Missile  Center  Technical  Publication.  4  September  1973.  Retrieved  3  June  2015.  Available  at 
http  ://www.  dtic.  mil/c  gi  -bin/GetTRDoc?  AD= AD07 66794. 
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Figure  A-3.  Theoretical  BEP  Performance  for  Various  Baseband  PCM  Signaling  Techniques 

(Perfect  Bit  Synchronization  Assumed) 

A.4.  PCM  Frame  Structure  Examples 

Table  A-2,  Table  A-3,  and  Table  A-4  show  examples  of  allowable  PCM  frame  structures. 
In  each  example,  the  minor  frame  sync  pattern  is  counted  as  one  word  in  the  minor  frame.  The 
first  word  after  the  minor  frame  sync  pattern  is  word  1.  Table  A-3  and  Table  A-4  show  the 
preferred  method  of  placing  the  SFID  counter  in  the  minor  frame.  The  counter  is  placed  before 
the  parameters  that  are  referenced  to  it. 

Major  frame  length  is  as  follows: 

•  Table  A-2:  Major  frame  length  =  minor  frame  maximum  length. 

•  Table  A-3:  Major  frame  length  =  minor  frame  maximum  length  multiplied  by  Z. 

•  Table  A-4:  Major  frame  length  =  minor  frame  maximum  length  multiplied  by  Z. 


A-4 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  4,  July  2017 


Table  A-2.  Minor  Frame  Maximum  Length,  N  Words  or  B  Bits 


Class  I:  Shall  not  exceed  8192  bits  nor  exceed  1024  words 
Class  II:  16  384  Bits 


Word 

1 

Word 

2 

Word 

3 

Word 

4 

Word 

5 

Word 

6 

Word 

7 

Word 

8 

Word 

9 

Word 

10 

Word 

N-2 

Word 

N-1 

Minor 

Frame 

Sync 

Pattern 

Param 

AO 

Param 

Al 

Param 

A2 

Param 

A3 

Param 

A4 

Param 

A2 

Param 

A5 

Param 

A6 

Param 

A2 

Param 

A7 

Param 

A2 

Param 

A(X) 

Parameters  AO,  Al,  A3,  A4,  A5,  A6, ...  A(X)  are  sampled  once  each  minor  frame. 
Parameter  A2  is  supercommutated  on  the  minor  frame. 

The  rate  of  A2  is  equal  to  the  number  of  samples  multiplied  by  the  minor  frame  rate. 
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Table  A-3.  Major  Frame  Length  =  Minor  Frame  Maximum  Length  Multiplied  by  Z 

Minor  Frame  Maximum  Length,  N  Words  or  B  Bits 

Class  I  shall  not  exceed  8192  bits  nor  exceed  1024  words.  Class  II:  16  384  bits. 


Word 

I 


Word 

2 


Word 

3 


Minor 
frame  sync 
pattern 


Minor 
frame  sync 
pattern 


SFID= 

I 


SFID= 

2 


SFID= 

3 


SFID= 

4 


SFID= 

5 


SFID= 

6 


SFID= 

7 


SFID 

=Z 


FFI 


Word 

4 


Word 

5 


Word 

6 


Param 

A2 


FFI 


Param 

A2 


Param 

BI 


Param 

B2 


Param 

B3 


Param 

B4 


Param 

B2 


Param 

B5 


Param 

B6 


Param 

B2 


Param 

BZ 


Param 

A4 


Word 

7 


Word 

8 


Word 

9 


Param 

A2 


Param 

A5 


Param 

A6 


Word 

10 


Param 

A2 


Param 

A4 


Param 

Cl 


Param 

C2 


Param 

C3 


Param 

C4 


Param 

C5 


Param 

C6 


Param 

Cl 


Param 

C(Z-I) 


Param 

Param 

Param 

Param 

Param 

Param 

Param 

A2 

A5 

A6 

A2 

CZ 

•  •  • 

A2 

A(X) 

Word 

N-2 


Word 

N-I 


Param 

A2 


Param 

A(X) 


The  frame  format  identifier  (word  2)  is  shown  in  the  preferred  position  as  the  first  word  following  the  ID  counter.  Parameters  BI, 
B3,  B4,  B5, .  .  .  BZ,  and  Cl,  C2,  C3, . .  .  CZ  are  sampled  once  each  subframe,  at  1/Z  multiplied  by  the  minor  frame  rate.  Parameter 
B2  is  supercommutated  on  the  subframe  and  is  sampled  at  less  than  the  minor  frame  rate,  but  greater  than  the  subframe  rate. 
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Table  A-4.  Major  Frame  Length  =  Minor  Frame  Maximum  Length  Multiplied  by  Z 

Minor  Frame  Maximum  Length,  N  Words  or  B  Bits 


H -  Class  I  shall  not  exceed  8192  bits  or  exceed  1024  words.  Class  II:  16  384  bits.  - ► 


Word 

1 

Word 

2 

Word 

3 

Word 

4 

Word 

5 

Word 
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SFIDl  has  a  depth  Z<  256;  SFID2  has  a  depth  D  <Z.  Z  divided  by  D  is  not  an  integer. 

Location  of  the  B  and  C  parameters  are  given  by  the  minor  frame  word  number  and  the  SFIDl  counter. 
Location  of  the  E  parameters  are  given  by  the  minor  frame  word  number  and  the  SFID2  counter. 
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CHAPTER  5 

Digitized  Audio  Telemetry  Standard 


5.1  General 

This  chapter  defines  continuously  variable  slope  delta  (CVSD)  modulation  as  the 
standard  for  digitizing  audio  and  addresses  the  method  of  inserting  CVSD  encoded  audio  into  a 
pulse  code  modulation  (PCM)  stream.  Additional  information  and  recommendations  are 
provided  in  Appendix  5-A,  which  was  extracted  from  the  applicable  sections  of  Military 
Standard  188-113,  which  has  been  canceled  with  no  replacement. 

Additional  information  regarding  the  insertion  of  the  digitized  voice  signal  into  a  PCM 
frame  may  be  obtained  in  the  documentation  of  US  Patent  5,557,635.* 

5.2  Definitions 

For  the  purpose  of  this  standard,  the  following  definitions  apply. 

Band-Limited  Audio:  An  audio  signal  (typically  consisting  of  voice,  tones,  and  sounds)  that  is 
limited  to  a  subset  of  the  audio  spectrum.  For  most  aircraft  audio  applications,  the 
spectrum  between  100  and  2300  hertz  (Hz)  is  adequate. 

Continuously  Variable  Slope  Delta  Modulation:  The  CVSD  modulation  is  a  method  of  digitizing 
a  band- limited  audio  signal.  The  CVSD  modulator  is,  in  essence,  a  1-bit  analog-to-digital 
converter.  The  output  of  this  1-bit  encoder  is  a  serial  bit  stream,  where  each  bit 
represents  an  incremental  increase  or  decrease  in  signal  amplitude  and  is  determined  as  a 
function  of  recent  sample  history. 

5.3  Signal  Source 

The  signal  to  be  encoded  shall  be  a  band-limited  audio  signal.  The  source  of  this  signal 
may  be  varied.  Some  examples  are  microphones,  communication  systems,  and  tones  from 
warning  systems.  This  standard  applies  to  audio  signals  only. 

5.4  Encoding/Decoding  Technique 

The  technique  to  encode  and  decode  the  band-limited  audio  signal  is  CVSD  modulation. 
This  technique  is  to  be  implemented  in  accordance  with  Appendix  5-A. 

A  CVSD  converter  consists  of  an  encoder-decoder  pair.  The  decoder  is  connected  in  a 
feedback  path.  The  encoder  receives  a  band-limited  audio  signal  and  compares  it  to  the  analog 
output  of  the  decoder.  The  result  of  the  comparison  is  a  serial  string  of  “ones”  and  “zeros.” 

Each  bit  indicates  that  the  band-limited  audio  sample’s  amplitude  is  above  or  below  the  decoded 
signal.  When  a  run  of  three  identical  bits  is  encountered,  the  slope  of  the  generated  analog 
approximation  is  increased  in  its  respective  direction  until  the  identical  string  of  bits  is  broken. 
The  CVSD  decoder  performs  the  inverse  operation  of  the  encoder  and  regenerates  the  audio 
signal. 


'  Daniel  T.  Laird.  Voice  encode/decode  subsystem  in  a  system  for  acquisition  of  test  data  using  pulse  code 
modulation.  US  Patent  5,557,635,  filed  September  28,  1994  and  issued  September  17,  1996. 
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NOTE 


A  qualitative  test  of  CVSD  with  a  tactical  aircraft  intercom  system  yielded  the 
following  results:  (1)  intelligible,  robotic  sounding  audio  at  12  kilobits  per 
second  (kbps);  (2)  good  quality  audio  at  16  kbps;  and  (3)  audio  quality  did  not 
significantly  improve  as  the  bit  rate  was  increased  above  32  kbps. 


5.5  CVSD  Encoder  Output  Bit  Rate  (CVSD  Bit  Rate) 

The  CVSD  bit  rate  for  encoding  the  band-limited  audio  signal  is  a  function  of  the  desired 
audio  quality  and  the  PCM  format  characteristics.  The  minimum  and  maximum  CVSD  bit  rates 
will  not  be  specified. 

Appendix  5-A  contains  performance  criteria  for  the  CVSD  encoder  and  decoder  when 
operated  at  16  or  32  kbps. 

5.6  CVSD  Word  Structure 

The  digitized  audio  signal  from  the  CVSD  encoder’s  serial  output  shall  be  inserted  into 
the  PCM  stream  as  shown  in  Figure  5-1.  The  most  significant  bit  (msb)  shall  be  the  most  stale 
sample  (first  in).  The  least  significant  bit  (Isb)  shall  be  the  most  recent  sample  (last  in). 


Most  Stale 
Sample 

CVSD  SERIAL  OUTPUT  STREAM 

Most  Recent 
Sample 

- 

S-2 

S-1 

S 

S+1 

•  •  • 

S+(n-l) 

S+n 

S+(n+l) 

- 

1 

1 

1 

1 

PCM  Data  Word 

S 

s+1 

•  •  • 

S+(n-l) 

PCM  Data  Word 

msb 

Isb 

Figure  5- 1 .  Insertion  of  CVSD-Encoded  Audio  into  a  PCM  Stream 


5.7  CVSD  Word  Sample  Rate 

The  CVSD  word  sample  rate  is  dependent  on  the  minimum  desired  CVSD  bit  rate,  the 
PCM  word  length,  and  the  PCM  word  sample  rate.  Once  the  CVSD  word  sample  rate  is 
determined,  the  actual  CVSD  bit  rate  can  be  calculated.  The  decoder  must  be  run  at  the  same 
CVSD  bit  rate  as  the  encoder. 


NOT^^ 

Because  of  the  nature  of  CVSD  encoding,  over  and  under 
sampling  of  the  CVSD  output  will  have  unpredictable  results. 

NOT^^ 

To  simplify  the  reconstruction  of  the  audio  signal  and 
minimize  all  encoding/decoding  delays,  it  is  STRONGEY 
recommended  that  the  digitized  audio  words  be  inserted  in  the 
PCM  stream  at  evenly  spaced  intervals. 

5-2 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  5,  July  2017 


5.8  CVSD  Bit  Rate  Determination 

The  following  discussion  provides  a  procedure  for  determining  the  CVSD  bit  rate  based 
on  the  desired  minimum  CVSD  bit  rate  and  information  given  in  the  host  PCM  format.  Note  that 
this  procedure  assumes  the  CVSD  words  are  inserted  in  a  class  I  PCM  format  with  constant  word 
widths  and  are  not  subcommutated.  The  CVSD  bit  rate  can  be  obtained  by  multiplying  the 
minor  frame  rate  by  the  number  of  times  the  CVSD  words  appear  in  the  minor  frame  by  the  word 
width  used  for  the  CVSD  words  in  the  minor  frame.  This  relationship  is  expressed  in  equation 
(5-1). 

CVSD  Bit  Rate  =  Minor  Frame  Rate  •  #CVSD  Words  per  Minor  Frame  •  Word  Width  (5-1) 

Knowing  the  details  on  the  host  PCM  format,  equation  (5-1)  contains  two  unknowns: 
CVSD  bit  rate  and  #CVSD  words  per  minor  frame.  One  of  these  unknowns  must  be  chosen  by 
the  user;  then  the  other  one  can  be  calculated.  The  recommended  procedure  is  to  choose  the 
desired  (target  value)  CVSD  bit  rate  and  solve  equation  (5-1)  for  #CVSD  words  per  minor  frame. 
This  relationship  is  expressed  in  equation  (5-2). 

DESIRED  CVSD  BIT  RATE 

#CVSD  WORDS  PER  MINOR  ERAME  =  - 

MINOR  ERAME  RATE  •  WORD  WIDTH  (5.2) 

Next,  round  up  (if  required)  the  result  of  equation  (5-2)  to  the  nearest  integer.  To  satisfy 
the  evenly  spaced  recommendation,  round  up  (if  required)  to  the  nearest  integer  that  divides 
evenly  into  the  number  of  PCM  words  per  minor  frame. 

Finally,  for  either  case,  substitute  the  result  of  equation  (5-2)  back  into  equation  (5-1)  to 
determine  the  actual  CVSD  bit  rate.  To  illustrate  this  procedure,  consider  the  following 
numerical  example  for  determining  the  CVSD  bit  rate.  An  existing  PCM  format  has  the 
characteristics: 


Bit  rate  =  192,000  bits/second 
Word  width  =12  bits/word 
Minor  frame  rate  =100  frames/second 
Words/  minor  frame  =160  words/minor  frame 


To  insert  a  serial  CVSD  bit  stream  with  a  desired  (target  value),  CVSD  bit  rate  of  16,000 
bits/second  will  require  the  following  procedure.  Based  on  the  information  given,  use  equation 
(5-2)  to  calculate  the  #CVSD  words  per  minor  frame. 


#CVSD  WORDS  PER  MINOR  FRAME 


CALCULATED 


#CVSD  WORDS  PER  MINOR  FRAME 


CALCULATED 


DESIRED  CVSD  BIT  RATE 
MINOR  FRAME  RATE  •  WORD  WIDTH 
16  000  {bitsj sec) 

100  {frames/ sec)  •  12  {bits/ word) 


#CVSD  WORDS  PER  MINOR  FRAMEcalculated  =  13.3  words/frame 

Rounding  up  the  #CVSD  words  per  minor  frame  to  the  nearest  integer  yields  14.  In  this 
example,  there  are  160  PCM  words  in  the  minor  frame.  If  the  user  needs  to  satisfy  the  evenly 
spaced  criteria,  then  by  inspection,  the  #CVSD  words  per  minor  frame  will  be  rounded  up  to  16. 
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For  comparison,  both  cases  will  be  substituted  into  equation  (5-1)  to  yield  the  actual  CVSD  bit 
rate. 

CASE  1:  (unevenly  spaced  CVSD  samples,  NOT  RECOMMENDED) 

#CVSD  WORDS  PER  MINOR  FRAME  calculated  =  {words j frame) 

CVSD  BIT  RATE  =  MINOR  FRAME  RATE  •  #CVSD  WORDS  /  MINOR  FRAME  •  WORD  WIDTH 
CVSD  BIT  RATE  actual  ~  100  {frame sj&ec)  •  \A  {wordsj frame)  •  \2  {bits j word) 

CVSD  BIT  RATE  actual  =  16  800  {bitsl&ec) 

CASE  2:  (evenly  spaced  samples,  RECOMMENDED) 

#CVSD  WORDS  PER  MINOR  FRAME  calculated  =  16  {wordsj frame) 

CVSD  BIT  RATE  =  MINOR  FRAME  RATE  •  # CVSD  WORDS  PER  MINOR  FRAME  •  WORD  WIDTH 
CVSD  BIT  RATE  =  100  {frames j&ec)  •  16  {wordsj frame)  •  12  {bitsj word) 

CVSD  BIT  RATE  actual  =  19  2  00  (bits/sec) 
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APPENDIX  5-A 

Continuously  Variable  Slope  Delta  Modulation 


A.l.  General 

The  CVSD  modulation  is  a  nonlinear,  sampled  data,  feedback  system  which  accepts  a 
band-limited  analog  signal  and  encodes  it  into  binary  form  for  transmission  through  a  digital 
channel.  At  the  receiver,  the  binary  signal  is  decoded  into  a  close  approximation  of  the  original 
analog  signal.  A  typical  CVSD  converter  consisting  of  an  encoder  and  decoder  is  shown  in 
Figure  A-1  and  Figure  A-2. 


Figure  A-1.  Typical  CVSD  Encoder 


Figure  A-2.  Typical  CVSD  Decoder 


A.2.  General  Descriptions 

A  general  description  of  the  delta  modulation  and  the  CVSD  converter  can  be  found  in 
the  following  subparagraphs. 

A. 2. a.  Delta  Modulation 

Delta  modulation  is  an  A-D  conversion  technique  resulting  in  a  form  of  digital  pulse 
modulation.  A  delta  modulator  periodically  samples  the  amplitude  of  a  band-limited  analog 
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signal,  and  the  amplitude  differences  of  two  adjacent  samples  are  coded  into  n-bit  code  words. 
This  nonlinear,  sampled-data  feedback  system  then  transmits  the  encoded  bit  stream  through  a 
digital  channel.  At  the  receiving  end,  an  integrating  network  converts  the  delta-modulated  bit 
stream  through  a  decoding  process  into  a  close  approximation  of  the  original  analog  signal. 

A.2.b.  CVSD  Converter 

A  typical  CVSD  converter  consists  of  an  encoder  and  a  decoder  (see  Figure  A-1  and 
Figure  A-2).  The  analog  input  signal  of  the  CVSD  encoder  is  band- limited  by  the  input  band, 
pass  filter.  The  CVSD  encoder  compares  the  band-limited  analog  input  signal  with  an  analog 
feedback  approximation  signal  generated  at  the  reconstruction  integrator  output.  The  digital 
output  signal  of  the  encoder  is  the  output  of  the  first  register  in  the  “run-of-three”  counter.  The 
digital  output  signal  is  transmitted  at  the  clock  (sample)  rate  and  will  equal  “1”  if  the  analog 
input  signal  is  greater  than  or  equal  to  the  analog  feedback  signal  at  the  instant  of  sampling.  For 
this  value  of  the  digital  output  signal,  the  pulse  amplitude  modulator  (PAM)  applies  a  positive 
feedback  pulse  to  the  reconstruction  integrator;  otherwise,  a  negative  pulse  is  applied.  This 
function  is  accomplished  by  the  polarity  control  signal,  which  is  equal  to  the  digital  encoder 
output  signal.  The  amplitude  of  the  feedback  pulse  is  derived  by  means  of  a  3-bit  shift  register, 
logic  sensing  for  overload,  and  a  syllabic  lowpass  filter.  When  a  string  of  three  consecutive  ones 
or  zeros  appears  at  the  digital  output,  a  discrete  voltage  level  is  applied  to  the  syllabic  filter,  and 
the  positive  feedback  pulse  amplitude  increases  until  the  overload  string  is  broken.  In  such  an 
event,  ground  potential  is  fed  to  the  filter  by  the  overload  algorithm,  forcing  a  decrease  in  the 
amplitude  of  the  slope  voltage  out  of  the  syllabic  filter.  The  encoder  and  decoder  have  identical 
characteristics  except  for  the  comparator  and  filter  functions. 

The  CVSD  decoder  consists  of  the  input  band  pass  filter,  shift  register,  overload 
algorithm,  syllabic  filter,  PAM  and  reconstruction  integrator  used  in  the  encoder,  and  an  output 
low-pass  filter.  The  decoder  performs  the  inverse  function  of  the  encoder  and  regenerates  speech 
by  passing  the  analog  output  signal  of  the  reconstruction  integrator  through  the  low-pass  filter. 
Other  characteristics  optimize  the  CVSD  modulation  technique  for  voice  signals.  These 
characteristics  include  the  following. 

a.  Changes  in  the  slope  of  the  analog  input  signal  determine  the  step-size  changes  of  the 
digital  output  signal. 

b.  The  feedback  loop  is  adaptive  to  the  extent  that  the  loop  provides  continuous  or  smoothly 
incremental  changes  in  step  size. 

c.  Companding  is  performed  at  a  syllabic  rate  to  extend  the  dynamic  range  of  the  analog 
input  signal. 

d.  The  reconstruction  integrator  is  of  the  exponential  (leaky)  type  to  reduce  the  effects  of 
digital  errors. 

A.3.  Detailed  Descriptions 

The  characteristics  described  in  subparagraphs  A. 3. a  through  A.3.i  are  in  addition  to 
those  specified  in  Section  A. 5  and  are  for  guidance  only. 
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A. 3. a.  Input  Band  Pass  Filter 

The  input  filter  provides  band-limiting  and  is  typically  a  second-  or  higher-order  filter 
(see  Figure  A-1). 

A.3.b.  Comparator 

The  comparator  compares  the  band-limited  analog  input  signal  from  the  filter  with  the 
output  signal  of  the  reconstruction  integrator  (see  Figure  A-1).  This  comparison  produces  the 
digital  error  signal  input  to  the  3-bit  shift  register.  The  transfer  characteristic  of  the  comparator 
is  such  that  the  difference  between  the  two  input  signals  causes  the  output  signal  to  be  driven  to 
saturation  in  the  direction  of  the  sign  of  the  difference. 

A.3.C.  3-Bit  Shift  Register 

The  3-bit  shift  register  acts  as  a  sampler  which  clocks  the  digital  error  signal  from  the 
comparator  at  the  specified  data  signaling  rate  and  stores  the  current  samples  and  two  previous 
samples  of  the  error  signal  (see  Figure  A-1  and  Figure  A-2).  The  digital  output  signal  is  a  binary 
signal  having  the  same  polarity  as  the  input  signal  from  the  comparator  at  the  time  of  the  clock 
signal.  The  digital  output  signal  is  also  the  digital  output  of  the  encoder  and  is  referred  to  as  the 
baseband  signal.  Further  processing  for  transmission  such  as  conditioned  diphase  modulation 
may  be  applied  to  the  baseband  signal.  It  is  necessary  that  the  inverse  of  any  such  processing  be 
accomplished  and  the  baseband  signal  restored  before  the  CVSD  decoding  process  is  attempted. 

A.3.d.  Overload  Algorithm 

The  overload  algorithm  operates  on  the  output  of  the  3-bit  shift  register  (X,  Y,  Z)  using 

the  run-of-threes  coincidence  algorithm  so  that  the  algorithm  output  equals  (  )  (see 

Figure  A-1  and  Figure  A-2).  The  output  signal  is  a  binary  signal  at  the  clock  signaling  rate  and 
is  true  for  one  clock  period  following  the  detection  of  three  like  bits  and  false  at  all  other  times. 

A.3.e.  Syllabic  Filter 

The  syllabic  filter  acts  as  a  low-pass  filter  for  the  output  signal  from  the  overload 
algorithm  (see  Figure  A- 1  and  Figure  A-2).  The  slope- voltage  output  of  the  syllabic  filter  is  the 
modulating  input  to  the  PAM.  The  step-function  response  of  the  syllabic  filter  is  related  to  the 
syllabic  rate  of  speech,  is  independent  of  the  sampling  rate,  and  is  exponential  in  nature.  When 
the  overload  algorithm  output  is  true,  a  charging  curve  is  applicable.  When  this  output  is  false,  a 
discharging  curve  is  applicable. 

A.3.f.  Pulse  Amplitude  Modulator 

The  PAM  operates  with  two  input  signals:  the  output  signal  from  the  syllabic  filter  and 
the  digital  signal  from  the  3-bit  shift  register  (see  Figure  A-1  and  Figure  A-2).  The  syllabic  filter 
output  signal  determines  the  amplitude  of  the  PAM  output  signal  and  the  signal  from  the  3-bit 
shift  register  is  the  polarity  control  that  determines  the  direction,  plus  or  minus,  of  the  PAM 
output  signal.  The  phrase  “continuously  variable”  in  CVSD  is  derived  from  the  way  the  PAM 
output  signal  varies  almost  continuously. 
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A.3.g.  Reconstruction  Integrator 

The  reconstruction  integrator  operates  on  the  output  signal  of  the  PAM  to  produce  an 
analog  feedback  signal  to  the  comparator  (or  an  output  signal  to  the  output  low-pass  filter  in  the 
receiver)  that  is  an  approximation  of  the  analog  input  signal  (see  Figure  A-1  and  Figure  A-2). 

A.3.h.  Output  Low-Pass  Filter 

The  output  filter  is  a  low-pass  filter  having  a  frequency  response  that  typically  has  an 
asymptotic  rolloff  with  a  minimum  slope  of  40  decibels  (dB)  per  octave,  and  a  stopband  rejection 
that  is  45  dB  or  greater  (see  Figure  A-2).  The  same  output  filter  characteristic  is  used  for 
encoder  digital  output  signals  of  either  16  or  32  kbps. 

A.3.i.  Typical  CVSD  Decoder  Output  Envelope  Characteristics 

For  a  resistance/capacitance  circuit  in  the  syllabic  filter  with  time  constants  of  5 
microseconds  (ps)  for  both  charging  and  discharging,  the  envelope  characteristics  of  the  signal  at 
the  decoder  output  are  shown  in  Figure  A-3.  For  the  case  of  switching  the  signal  at  the  decoder 
input  from  the  0  percent  run-of-threes  digital  pattern  to  the  30  percent  run-of-threes  digital 
pattern,  the  characteristic  of  the  decoder  output  signal  follows  the  resistance/capacitance  charge 
curve.  Note  that  the  number  of  time  constants  required  to  reach  the  90  percent  charge  point  is 
2.3,  which  gives  a  nominal  charge  time  of  1 1.5  ps. 


Figure  A-3.  Typical  Envelope  Characteristics  of  the  Decoder  Output  Signal  for  CVSD 


When  switching  the  other  way  (from  the  30  percent  pattern  to  the  0  percent  pattern),  the 
amplitude  at  the  beginning  of  discharging  is,  at  the  first  moment  of  switching,  higher  (by  a  factor 
of  16)  than  the  final  value  which  is  reached  asymptotically.  The  final  value  equals  -24  dBmO, 
that  is,  0.03.  Therefore,  the  amplitude  at  the  beginning  of  discharging  is  0.48  (percent  run-of- 
threes  =  0).  Note  that  the  number  of  time  constants  required  to  reach  the  10  percent  point  on  the 
discharge  curve  is  1.57,  which  gives  a  nominal  discharge  time  of  7.8  ps. 
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A.4.  Reference  Level 

The  decoder  analog  output  level  with  the  16  and  32  kbps,  30  percent  run-of-threes 
reference  digital  pattern  applied  to  the  decoder  input  shall  be  the  reference  level  for  the  CVSD 
requirements  of  this  standard  and  shall  be  designated  0  dBmO  (see  Subparagraph  A.5.i(l)). 


A.5.  CVSD  Characteristics 

The  characteristics  of  CVSD  are  described  in  the  following  subparagraphs. 

A. 5. a.  Input  and  Output  Impedances 

The  analog  input  and  output  impedances  for  CVSD  converters  are  not  standardized. 
These  impedances  depend  upon  the  application  of  the  converters. 

A.5.b.  Data  Signaling  Rates 

The  CVSD  converter  shall  be  capable  of  operating  at  16  and  32  kbps. 


A.5.C.  Input  and  Output  Filters 


The  analog  input  shall  be  band  pass  filtered.  The  analog  output  shall  be  low  pass  filtered. 


NOTE 


Details  of  input  and  output  filers,  consistent  with  the  CVSD  performance 
requirements  of  this  standard,  will  be  determined  in  applicable  equipment 
specifications  based  on  validated  requirements 


A.5.d.  Overload  Algorithm 

A  3-bit  shift  register  shall  be  used  for  the  CVSD  encoder  and  decoder  (see  Figure  A-1 
and  Figure  A-2).  The  overload  logic  shall  operate  on  the  output  of  this  shift  register  using  the 
run-of-threes  coincidence  algorithm.  The  algorithm  output  signal  shall  be  a  binary  signal  at  the 
data-signaling  rate.  This  signal  shall  be  true  for  one  clock  period  following  the  detection  of  three 
like  bits  (all  Os  or  all  Is)  and  false  at  all  other  times. 

A.5.e.  Compression  Ratio 

The  compression  ratio  shall  be  nominally  16:1  with  a  maximum  of  21:1  and  a  minimum 
of  12:1.  The  maximum  slope  voltage  shall  be  measured  at  the  output  of  the  syllabic  filter  for  a 
30  percent  run-of-threes  digital  pattern.  The  minimum  slope  voltage  shall  be  measured  at  the 
output  of  the  syllabic  filter  for  a  0  percent  run-of-threes  digital  pattern. 

A.5.f.  Syllabic  Filter 

The  syllabic  filter  shall  have  a  time  constant  of  5  ps  +1.  The  step  function  response  of 
the  syllabic  filter  shall  be  exponential  in  nature.  When  the  output  of  the  overload  algorithm  is 
true,  a  charge  curve  shall  be  applicable.  When  the  output  of  the  overload  algorithm  is  false,  a 
discharge  curve  shall  be  applicable. 

A.5.g.  Reconstruction  Integrator  Time  Constant 

The  reconstruction  integrator  shall  have  a  time  constant  of  1  ps  +0.25. 
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A.5.h.  Analog-to-Digital  Conversion 

An  800-Hz  +10  signal  at  a  0  dBmO  level  applied  to  the  input  of  the  encoder  shall  give  a 
duty  cycle  of  0.30  at  the  algorithm  output  of  the  encoder  shown  in  Figure  A-1. 

A.5.i.  Digital-to- Analog  Conversion 

The  characteristics  of  a  digital-to- analog  conversion  are  described  in  the  following 
subparagraphs. 

A.5.i(l)  Relation  of  Output  to  Input 

With  the  applicable  reference  digital  patterns  of  Table  A-1  applied  to  the  digital  input  of 
the  decoder  as  shown  in  Figure  A-4,  the  analog  output  signal  shall  be  800  Hz  +10  at  the  levels 
shown  in  Table  A-1,  measured  at  the  decoder  output.  These  digital  patterns,  shown  in 
hexadecimal  form,  shall  be  repeating  sequences. 


Table  A-1.  Decoder  Reference  Digital  Patters  for  CVSD 

Data  Signaling  Rate  (kbps) 

Digital  Pattern 

Run-of-threes  (percent) 

Output  (dBmO) 

16 

DB492 

0 

-24+1 

32 

DB54924AB6 

0 

-24+1 

16 

FB412 

30 

0+1 

32 

FDAA10255E 

30 

0+1 

ENCODER 

INPUT 


ENCODER 

OUTPUT 


INTERFACE  POINTS 


DECODER 

INPUT 


DECODER 

OUTPUT 


■AN.ALOG  SIGNAL 

INPUT 


:ncoder 


RFFFRFNCF  DTGT  AT 

PATTERN  INTUT 


DIGIT.4L  TR.UNSMISSION 
^  16  kbps  OR  32  kbps 


►O 


DECODER 


►a 


■A\-.\LOG  SIGN^ 

OUTPUT 


DECODER 


^10  ANALOG  SIGNAq 
OUTPUT 


Figure  A-4.  Interface  Diagram  for  CVSD  Converter 


A.5.i(2)  Conversion  Speed 

When  the  decoder  input  is  switched  from  the  0  percent  run-of-threes  digital  pattern  to  the 
30  percent  run-of-threes  digital  pattern,  the  decoder  output  shall  reach  90  percent  of  its  final 
value  within  9  to  14  ps.  When  the  decoder  input  is  switched  from  the  30  percent  run-of-threes 
digital  pattern  to  the  0  percent  run-of-threes  digital  pattern,  the  decoder  output  shall  reach  10 
percent  of  the  30  percent  run-of-threes  value  within  6  to  9  ps.  These  values  shall  apply  to  both 
the  16-  and  32-kbps  data  signaling  rates. 

A.5.j.  CVSD  Converter  Performance 

The  characteristics  specified  in  subparagraphs  A. 5. id)  through  A.5.i(7)  apply  to  one 
CVSD  conversion  process  obtained  by  connecting  the  output  of  an  encoder  to  the  input  of  a 
decoder  (see  Figure  A-4). 
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NOTE 


Test  signal  frequencies  that  are  submultiples  of  the  data  signaling  rate  shall  be 
avoided  by  offsetting  the  nominal  test  frequency  slightly;  for  example,  an 
800-Hz  test  frequency  could  be  offset  to  804  Hz.  This  test  frequency  offset 
will  avoid  nonlinear  distortion,  which  can  cause  measurement  difficulties 
when  CVSD  is  in  tandem  with  PCM. 


A .  5 . j  ( 1 )  Companding  Speed 

When  an  800-Hz  +10  sine  wave  signal  at  the  encoder  input  is  switched  from  -24  dBmO 
to  0  dBmO,  the  decoder  output  signal  shall  reach  90  percent  of  its  final  value  within  9  to  14  ps. 

A.5.j(2)  Insertion  Loss 

The  insertion  loss  between  the  encoder  input  and  the  decoder  output  shall  be  0  dB  +2  dB 
with  an  800  Hz  +10,  0  dBmO  input  to  the  encoder. 

A.5.j(3)  Insertion  Loss  vs.  Frequency  Characteristics 

The  insertion  loss  between  the  encoder  input  and  decoder  output,  relative  to  800  Hz  +10 
measured  with  an  input  level  of  -15  dBmO  applied  to  the  converter  input,  shall  not  exceed  the 
limits  indicated  in  Table  A-2  and  shown  in  Figure  A- 5  and  Figure  A-6. 


Table  A-2.  Insertion  Loss  Limits  for  CVSD 

Rate  (kbps) 

Frequency  (f)  (Hz) 

Insertion  Loss  (dB) 
(Referenced  to  800  Hz) 

16 

f<300 

>-1.5 

300  <f>  1000 

-1.5  to  1.5 

1000<f>2600 

-5  to  1.5 

2600<f>4200 

>-5 

4200  <  f 

>25 

32 

f<300 

>-l 

300  <f>  1400 

-1  to  1 

1400<f>2600 

3  to  1 

2600<f>3400 

3  to  2 

3400<f>4200 

>-3 

4200  <  f 

>25 
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Figure  A-5.  Insertion  Loss  vs.  Frequency  for  CVSD  (16  kbps) 


Figure  A-6.  Insertion  Loss  vs.  Frequency  for  CVSD  (32  kbps) 


A.5.j(4)  Variation  of  Gain  With  Input  Level 

The  variation  in  output  level,  relative  to  the  value  at  -15  dBmO  input,  shall  be  within  the 
limits  of  Figure  A-7  and  Figure  A- 8  for  an  input  frequency  of  800  Hz  +10. 
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Figure  A-7.  Variation  of  Gain  With  Input  Level  for  CVSD  (16  kbps) 


A.5.j(5)  Idle  Channel  Noise 

The  idle  channel  noise  shall  not  exceed  the  limits  shown  in  Table  A- 3  when  measured  at 
the  CVSD  decoder  output. 


Table  A-3.  Idle  Channel  Noise  Limits  for  CVSD 

Data  Signaling  Rate  (kbps) 

Idle  Channel  Noise  (dBmO) 

16 

-40 

32 

-50 

A.5.j(6)  Variation  of  Quantizing  Noise  With  Input  Level 

The  minimum  signal  to  quantizing  noise  ratio  over  the  input  signal  level  range  shall  be 
above  the  limits  of  Figure  A- 9  and  Figure  A- 10.  The  noise  ratio  shall  be  measured  with  flat 
weighting  (unweighted)  at  the  decoder  output  with  a  nominal  800-Hz  +10  sine  wave  test  signal 
at  the  encoder  input. 
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Figure  A-9.  Signal  to  Quantizing  Noise  Ratio  vs.  Input  Level  for  CVSD  (16  kbps) 


Figure  A- 10.  Signal  to  Quantizing  Noise  Ratio  vs.  Input  Level  for  CVSD  (32  kbps) 

A.5.j(7)  Variation  of  Quantizing  Noise  With  Frequency 

The  minimum  signal  to  quantizing  noise  ratio  over  the  input  frequency  range  shall  be 
above  the  limits  of  Figure  A- 11  and  Figure  A- 12.  The  noise  ratio  shall  be  measured  with  flat 
weighting  (unweighted)  at  the  decoder  output  with  a  sine  wave  test  signal  of  -15  dBmO. 
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Figure  A-1 1.  Signal  to  Quantizing  Noise  Ratio  vs.  Frequency  for  CVSD  (16  Kbps) 


Figure  A-12.  Signal  to  Quantizing  Noise  Ratio  vs.  Frequency  for  CVSD  (32  Kbps) 
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ASCII 

Acronyms 

American  Standard  Code  for  Information  Interchange 

BC 

bus  controller 

BIT 

built-in  test 

C&C 

command  and  control 

CLI 

command  line  interface 

DHCP 

Dynamic  Host  Control  Protocol 

FTP 

File  Transfer  Protocol 

lAW 

in  accordance  with 

IBIT 

initiated  built-in  test 

iSCSI 

Internet  Small  Computer  System  Interface 

Isb 

least  significant  bit 

mA 

milliamps 

MIL-STD 

Military  Standard 

MRTFB 

Major  Range  and  Test  Facility  Base 

ms 

millisecond 

msb 

most  significant  bit 

MTU 

maximum  transmission  unit 

N/A 

not  applicable 

ORB 

operation  request  block 

PCM 

pulse  code  modulation 

ppm 

parts  per  million 

PTP 

Precision  Time  Protocol 

R/R 

recorder  and/or  reproducer 

RMM 

removable  memory  module 

RSCF 

recorder  setup  configuration  file 

RT 

remote  terminal 

SCSI 

Small  Computer  System  Interface 

SSD 

solid-state  disk 

TMATS 

Telemetry  Attributes  Transfer  Standard 

UDP 

User  Datagram  Protocol 

V 

volts 
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CHAPTER  6 

Recorder  &  Reproducer  Command  and  Control 

6.1  Introduction 

This  chapter  defines  the  standard  eommands,  queries,  and  status  information  when 
communicating  with  a  recorder  and/or  reproducer  (R/R)  that  uses  random  access  storage 
(typically  either  solid-state  or  magnetic  disk).  Not  all  commands  (CLI  or  discrete)  may  be 
applieable  to  all  types  of  R/R  implementations.  Commands  are  used  to  a)  eontrol  the  data  flow 
into  and  out  of,  b)  request  the  performanee  of  an  internal  operation  within,  and  e)  request  status 
information  from  an  R/R.  The  primary  intent  of  this  chapter  is  to  cover  terminology  included  in 
or  consistent  with  the  Chapter  10  standard.  The  CLI  and  discrete  interfaces  are  divided  into  two 
eategories  of  “eommand  sets”  as  follows: 

a.  Required:  The  minimum  set  of  diserete  and  CLI  commands  for  R/R  control,  query,  and 
status. 

b.  Optional:  The  optional  discrete  or  CLI  command  sets  that  may  or  may  not  be 
implemented  and  may  be  shown  as  referenees. 

This  chapter  standardizes  command  and  control  (C&C)  over  a  variety  of  different 
eleetrieal  interfaees.  These  eommands  ean  be  transmitted  via  various  eleetrieal  interfaees  (ports) 
defined  in  Seetion  10.7  of  Chapter  10,  including  Military  Standard  (MIL-STD)-1553,  RS-232, 
RS-422,  Small  Computer  System  Interface  (SCSI),  Fibre  Channel,  IEEE  1394  (EireWire), 
internet  SCSI  (iSCSI)  over  networks,  and  Telnet. 

When  an  R/R  simultaneously  supports  multiple  interfaces,  it  must  comply  with  the 
interface  and  command  precedence  specified  in  this  chapter.  While  this  standard  may  serve  as  a 
guide  in  the  proeurement  of  ground  and  airborne  reeorders,  it  is  not  intended  to  be  a  substitute 
for  a  purehase  speeifieation.  This  standard  does  not  necessarily  eonform  to,  nor  does  it  define, 
existing  or  planned  capabilities  of  any  given  test  range. 

6.1.1  Definitions  and  Acronyms 

As  of  RCC  106-17,  this  section  is  moved  to  Appendix  6-B. 

6.1.2  Storage  Media  Structure  Hierarchy 

Support  for  multiple  data  flows  to  and  from  multiple  storage  devices  requires  hierarchical 
structures  for  C&C.  The  following  terms  defined  in  Appendix  6-B  have  the  following  hierarchy 
from  lowest  layer  to  highest  layer. 

a.  Drive 

b.  Volume 
e.  Eile 

6.1.3  Data  Flows 

An  R/R  has  five  eategories  of  data  interfaees,  listed  below. 
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a.  Data  input 

b.  Data  output 

c.  R/R  to/from  Media 

d.  Network  port(s) 

e.  Download  port(s) 

The  figures  below  identify  eight  different  data  flows  between  these  interfaces  that  are 
initiated  or  terminated  by  commands  defined  in  this  chapter.  An  R/R  may  simultaneously 
support  more  than  one  of  these  data  flows. 

6. 1.3.1  Recording 

The  recording  data  flow  receives  live  data  from  input  data  channels  and  writes  the  data  in 
Chapter  10  format  to  the  media.  This  mode  can  be  activated  by  the  .RECORD  command. 

Figure  6- 1  depicts  the  recording  data  flow. 


DATA  INPUT 
CHANNELS 


NETWORK  /I _ l\ 

PORT(S)  \J - 1/ 


T7 


RECORDER 
and/or 
REPRODUCER 


MEDIA 


DOWNLOAD 

PORT(S) 


DATA  OUTPUT 
CHANNELS 


Figure  6- 1 .  Recording  Data  Flow 


6 . 1 . 3 . 2  Reproducing 

The  reproducing  data  flow  reads  Chapter  10  data  stored  in  a  file  on  the  media  and  sends  it 
out  on  data  output  channels.  Figure  6-2  depicts  the  reproducing  data  flow.  The  output  data 
format  may  or  may  not  be  the  same  as  the  original  input  format,  depending  on  the  capabilities  of 
that  unique  reproducer.  For  example,  video  originally  input  as  S-Video  (separate  Chroma  and 
Fuma)  may  be  output  as  composite.  Messages  in  MIF-STD-1553  format  captured  from  a  dual- 
redundant  bus  monitor  may  be  reproduced  as  a  Chapter  8  pulse  code  modulation  (PCM)  signal. 
This  mode  can  be  activated  by  the  .PFAY  command. 
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Figure  6-2.  Reproducing  Data  Flow 
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PORT{S) 


6. 1.3. 3  Simultaneous  Recording  and  Reproducing 

The  recording  and  reproducing  data  flows  can  be  combined  to  simultaneously  write  to 
and  read  from  the  media.  The  recording  and  reproducing  data  rates  are  independent,  and  the 
output  may  reproduce  more  or  fewer  channels  than  are  currently  being  input.  Starting  and 
stopping  the  recording  and  reproducing  are  also  independent  and  may  be  started  and  stopped  in 
any  order.  The  combined  flows  are  also  referred  to  as  “read-while- write.” 

6. 1.3. 4  Looping 

The  looping  data  flow  combines  data  input  with  data  output  using  a  common  time  base 
on  both  the  input  and  output.  The  looping  data  flow  can  be  divided  into  live  data  looping  and 
recorded  data  looping.  Looping  may  output  all  or  a  subset  of  the  input  channels. 

6. 1.3.4. 1  Looping  Live  Data 

Circuit-looping  live  data  does  not  utilize  the  drive.  Data  is  moved  from  the  input 
channels  directly  to  the  output  channels.  The  output  data  rates  are  derived  from  the  data  rate  of 
the  corresponding  data  input.  This  mode  can  be  activated  by  the  .ETOELOOP  command. 
Eigure  6-3  depicts  the  circuit- looping  live  data  flow. 
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6. 1.3.4. 2  Looping  Recorded  Data 

Media-looping  (or  drive-looping)  recorded  data  does  involve  the  media  and  is  commonly 
referred  to  as  “read-after- write.”  The  output  data  rates  are  derived  from  the  data  rate  of  the 
corresponding  data  input.  The  dotted  line  in  Figure  6-4  depicts  the  common  time  base  of  the 
recorded  and  reproduced  data  when  media-looping  recorded  data.  This  mode  can  be  activated  by 
the  .LOOP  command. 


6. 1.3.5  Publishing 

The  publishing  data  flow  is  used  to  transmit  live  or  recorded  data  in  Chapter  10  packet 
format  on  a  network  interface  (e.g.,  Ethernet);  note  that  the  network  interface  used  for  publishing 
will  typically  be  distinct  from  the  network  interface(s)  used  for  acquisition  or  reproduction. 

6. 1.3. 5.1  Publishing  Live  Data 

Live  data  publishing  provides  minimum  latency  between  input  of  live  data  in  raw  data 
format  and  output  of  packetized  Chapter  10  data  over  a  network  interface.  The  data  output  rate 
is  determined  by  the  live  data  input  rate.  Figure  6-5  depicts  the  broadcasting  live  data  flow.  The 
mode  can  be  activated  by  the  .PUBLISH  command. 
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Figure  6-5.  Publishing  Live  Data  Flow 
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6. 1.3. 5. 2  Publishing  Recorded  Data 

Recorded  data  publishing  enables  any  previously  recorded  data  to  be  transmitted  via  a 
network  interface  in  Chapter  10  packet  format.  The  transmitted  data  rate  is  limited  by  the  lesser 
of  the  drive  access  rate  and  the  available  network  bandwidth  and  may  optionally  be  constrained 
to  the  rate  at  which  the  data  was  recorded.  Figure  6-6  depicts  the  publishing  recorded  data  flow. 
The  mode  can  be  activated  by  the  .PUBLISH  FILE  command. 


6. 1.3.6  Downloading 

The  downloading  data  flow  transfers  Chapter  10  format  data  from  the  drive  to  the  host. 
For  drives  formatted  as  Chapter  10  volumes,  the  SCSI  protocol  may  be  used  by  the  host  to  access 
file  directories  and  data  files.  Downloading  files  from  non-Chapter  10  volumes  is  outside  the 
scope  of  this  standard.  Figure  6-7  depicts  the  downloading  data  flow. 
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DOWNLOAD 
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Figure  6-7.  Downloading  Data  Flow 


6. 1.3.7  Uploading 

The  uploading  data  flow  transfers  Chapter  10  format  data  from  the  host  to  the  drive.  For 
drive  formatted  as  Chapter  10  volumes,  the  SCSI  protocol  may  be  used  by  the  host  to  update  file 
directories  and  data  files.  Uploading  files  to  non-Chapter  10  volumes  is  outside  the  scope  of  this 
standard.  Figure  6-8  depicts  the  uploading  data  flow. 
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Figure  6-8.  Uploading  Data  Flow 


6.1.4  Recorder  and/or  Reproducer  States 

Previous  versions  of  the  R/R  C&C  identified  eleven  states  of  R/R  operation,  ten  of  which 
are  discrete  states  and  one  (07)  is  a  combination  of  two  states  (05  -i-  06). 


FAIL  (00) 

IDLE  (01) 

BIT  (02) 

ERASE  (03) 

DECEASSIEY  (04) 

RECORD  (05) 

PEAY  (06) 

RECORD  &  PEAY  (07) 

EIND  (08) 

BUSY  (09) 

COMMAND  ERROR  (10) 

The  addition  of  multiple  ports  and  drives  to  an  R/R  requires  the  definition  of  new  discrete 
states  and  new  composite  states.  The  state  numbers  have  been  redefined  so  their  value  is  the 
binary  representation  of  each  of  the  possible  discrete  states,  with  composite  states  represented  by 
simultaneous  assertion  of  multiple  discrete  state  bits.  The  use  of  legacy  state  values  is 
distinguished  from  the  use  of  these  redefined  state  values  by  their  ranges:  legacy  states  having 
the  values  0-10  and  new  states  beginning  with  16.  Table  6-1  shows  the  redefined  state  bits. 
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Table  6-1.  State  Bit  Assignments 
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reserved 

-  =  reserved  for  legacy  codes 

r  =  reserved 

X  =  don't  care 

The  R/R  states  are  defined  as  follows  (alphabetical  order,  at  least  one  of  these  bits  must 
always  be  set): 


BIT  -  A  built-in  test  (BIT)  is  in  progress 

BROADCAST  -  Transmit  live  or  recorded  data  out  of  an  Ethernet  interface  via  User  Datagram 

Protocol  (UDP)  packets 

BUSY  -  Transition  between  states 

CLEAN  -  The  drive  is  being  overwritten  with  all  Os  or  all  Is 

ERASE  -  The  file  table  on  the  drive  is  being  reset  to  empty 

EAULT  -  The  BIT  failed  and  further  diagnostics  are  required 

EIND  -  Locate  a  position  within  the  recorded  data  on  the  drive  for  subsequent  replay 

IDLE  -  The  R/R  is  powered  on,  ready  to  accept  commands,  and  no  data  flows  are  active 

LOOP  -  Reproduce  live  data  synchronously  with  data  input  with  or  without  recording 

RECORD  -  Input  data,  encapsulate  into  Chapter  10  packets,  and  store  on  the  drive 

REPRODUCE  -  Read  Chapter  10  data  from  the  drive  and  output  in  raw  form 

SANITIZE-  Perform  a  secure  erase  of  the  attached  drive 

R/R  Command  Results: 

COMMAND  PAIL  -  A  previous  operation,  such  as  BIT  or  EIND,  failed 
SANITIZE  PAIL  -  The  sanitize  procedure  failed 
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SANITIZE  PASS  -  The  sanitize  procedure  succeeded 

6.1.5  Recorder  and/or  Reproducer  Features 

Each  R/R  can  be  described  as  a  single  controller  with  one  or  more  channels,  one  or  more 
ports,  and  some  media  (typically  but  not  necessarily  consisting  of  one  or  more  discrete  drives). 

A  single  controller  unit  may  contain  multiple  processors  and/or  cores,  but  it  may  only  have  one 
command  sequence.  When  a  controller  is  capable  of  receiving  commands  simultaneously  from 
different  sources  into  its  single  command  sequence,  the  precedence  of  the  command  sources  and 
the  resultant  operational  sequence  shall  be  as  defined  in  this  C&C  standard.  Eor  example,  an 
R/R  may  have  a  discrete  switch  control  panel  located  at  the  R/R  site,  a  serial  port,  and  may  also 
be  connected  to  a  network  interface  for  remote  C&C  operation. 

Both  channels  and  ports  may  transport  data  and/or  control  information.  The 
differentiating  factor  is  that  data  transferred  across  ports  is  already  formatted  by  or  for  the  R/R 
R/R  (e.g.,  into  the  packet  format  mandated  by  Chapter  10),  whereas  data  transferred  across 
channels  is  not.  Each  data/control  channel  is  identified  by  a  channel  ID.  Each  data/control  port 
is  identified  by  a  port  ID.  .  The  combination  of  channels,  ports,  and  media  managed  by  the 
single  processor  unit  of  an  R/R,  and  the  controller  unit  itself,  are  all  features  of  the  R/R.  Note 
that  some  R/R  designs  will  have  additional  features,  such  as  multiple  distinct  media  types  or 
pools,  or  built-in  processing  capabilities  (e.g.,  for  real-time  display  of  data);  these  features  are 
neither  precluded  nor  defined  by  this  standard. 

6.1.6  System  Health 

The  system  health  of  an  R/R  can  be  stratified  into  two  attribute  levels:  common  (high- 
level)  and  device-specific  (low-level,  typically  vendor  unique).  Common  attributes,  such  as 
power-on  self-test  results,  are  independent  of  the  specific  tests  performed  by  unique  vendor 
system  architectures.  This  C&C  system  provides  a  method  for  reporting  required  health 
attributes  common  to  all  systems  and  discretionary  vendor- specific  health  attributes. 

This  C&C  system  further  divides  system  health  status  information  into  two  categories: 
critical  and  non-critical.  Critical  faults  are  typically  those  that  render  the  R/R  inoperable, 
whereas  non-critical  faults  are  informational  warnings.  This  C&C  system  enables  the  user  to 
establish  the  criticality  of  each  reported  system  health  attribute. 

The  health  of  each  feature  is  represented  by  a  32-bit  binary  word  in  which  each  bit 
represents  a  single  attribute  of  the  feature.  The  attributes  represented  by  bits  0  through  7  of  each 
feature  are  common  to  all  R/Rs  containing  those  features  and  are  defined  in  this  standard.  The 
attributes  represent  by  bits  8  through  3 1  are  unique  to  each  R/R  and  are  defined  separately  in 
vendor- specific  documents. 

Any  health  attribute  bit  that  is  set  (“1”)  indicates  a  warning  or  fault.  The  .HEAETH 
command  is  used  to  retrieve  the  current  state  of  the  health  attribute  bits  for  each  feature  of  the 
R/R.  Table  6-2  shows  the  common  attribute  bits  for  currently  defined  Chapter  10  data  types  and 
R/R  features. 


Table  6-2.  Use  of  Status  Bits 

Feature 

Bit 

Mask  (Hex) 

Description 

System 

0 

01 

BIT  Failure 
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Table  6-2.  Use  of  Status  Bits 

Feature 

Bit 

Mask  (Hex) 

Description 

1 

02 

Setup  Failure 

2 

04 

Operation  Failure 

3 

08 

Drive  Busy  Unable  to  Accept  Command 

4 

10 

No  Drive 

5 

20 

Drive  FO  Failure 

6 

40 

Drive  Almost  Full 

7 

80 

Drive  Full 

31-8 

Vendor-Specific  Health  Status  Bits 

Time  Code 

0 

01 

BIT  Failure 

1 

02 

Setup  Failure 

2 

04 

No  External  Signal 

3 

08 

Bad  External  Signal 

4 

10 

Synchronize  Eailure 

5 

20 

Reserved  for  future  Chapter  10  status  bit 

6 

40 

Reserved  for  future  Chapter  10  status  bit 

7 

80 

Reserved  for  future  Chapter  10  status  bit 

31-8 

Vendor-Specific  Health  Status  Bits 

PCM 

0 

01 

BIT  Eailure 

1 

02 

Setup  Eailure 

2 

04 

Bad  Clock  Eailure 

3 

08 

Bad  Data  Eailure 

4 

10 

Minor  Erame  Sync  Eailure 

5 

20 

Major  Erame  Sync  Eailure 

6 

40 

Bit  Sync  Eock  Eailure 

7 

80 

Watch  Word  Eailure 

31-8 

Vendor-Specific  Health  Status  Bits 

1553 

0 

01 

BIT  Eailure 

1 

02 

Setup  Eailure 

2 

04 

Response  Timeout  Error 

3 

08 

Eormat  Error 

4 

10 

Sync  Type  or  Invalid  Word  Error 

5 

20 

Word  Count  Error 

6 

40 

Reserved  for  future  Chapter  10  status  bit 

7 

80 

Watch  Word  Eailure 

31-8 

Vendor-Specific  Health  Status  Bits 

Video 

0 

01 

BIT  Eailure 

1 

02 

Setup  Eailure 

2 

04 

No  Video  Signal  Error 

3 

08 

Bad  Video  Signal  Error 

4 

10 

No  Audio  Signal  Error 

5 

20 

Bad  Audio  Signal  Error 
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Table  6-2.  Use  of  Status  Bits 

Feature 

Bit 

Mask  (Hex) 

Description 

6 

40 

Reserved  for  future  Chapter  10  status  bit 

7 

80 

Reserved  for  future  Chapter  10  status  bit 

31-8 

Vendor-Specific  Health  Status  Bits 

Analog 

0 

01 

BIT  Failure 

1 

02 

Setup  Failure 

2 

04 

No  Analog  Signal  Error 

3 

08 

Bad  Analog  Signal  Error 

4 

10 

Reserved  for  future  Chapter  10  status  bit 

5 

20 

Reserved  for  future  Chapter  10  status  bit 

6 

40 

Reserved  for  future  Chapter  10  status  bit 

7 

80 

Reserved  for  future  Chapter  10  status  bit 

31-8 

Vendor-Specific  Health  Status  Bits 

Image  or 
Message 

0 

01 

BIT  Eailure 

1 

02 

Setup  Eailure 

2 

04 

Bad  Signal  Error 

3 

08 

Data  Content  Error 

4 

10 

Reserved  for  future  Chapter  10  status  bit 

5 

20 

Reserved  for  future  Chapter  10  status  bit 

6 

40 

Reserved  for  future  Chapter  10  status  bit 

7 

80 

Reserved  for  future  Chapter  10  status  bit 

31-8 

Vendor-Specific  Health  Status  Bits 

Other  Types 

0 

01 

BIT  Eailure 

1 

02 

Setup  Eailure 

2 

04 

Bad  Signal  Error 

3 

08 

Data  Content  Error 

4 

10 

Reserved  for  future  Chapter  10  status  bit 

5 

20 

Reserved  for  future  Chapter  10  status  bit 

6 

40 

Reserved  for  future  Chapter  10  status  bit 

7 

80 

Reserved  for  future  Chapter  10  status  bit 

31-8 

Vendor-Specific  Health  Status  Bits 

Drive 

0 

01 

BIT  Eailure 

1 

02 

Setup  Eailure  (Mount) 

2 

04 

Operation  Eailure  (Processor  Command) 

3 

08 

Drive  Busy  Unable  to  Accept  Command 

4 

10 

No  Drive 

5 

20 

Drive  EO  Eailure 

6 

40 

Drive  Almost  Eull 

7 

80 

Drive  Eull 

31-8 

Vendor-Specific  Health  Status  Bits 
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For  single-drive  configurations,  a  single-drive  health  status  can  be  reported  by  bits  in  the 
System  feature.  For  configurations  with  multiple  drives,  each  drive  is  a  separate  feature 
specified  by  the  drive  ID  in  the  .HEALTH  command. 

When  the  Drive  feature  is  used  the  feature  numbers  shall  not  be  changed  (re-assigned) 
when  the  drives  are  removed  /  re-plugged  from  /  to  the  R/R.  The  drive  ID  number  shall  start  at  0 
and  use  the  same  drive  numbering  as  defined  in  the  setup  record. 

6.2  CLI  Command  and  Control 

This  standard  defines  a  set  of  commands  used  to  control  and  monitor  the  operation  of 
R/Rs.  The  availability  of  each  command  depends  on  the  feature  set  of  the  controlled  R/R  and  the 
specific  control  port  used  to  send  commands  to  and  receive  replies  from  the  R/R.  Table  6-3  lists 
the  commands  in  alphabetical  order  grouped  as  the  mandatory  commands  followed  by  optional 
ones.  The  protocols  used  to  send  these  commands  to  an  R/R  and  receive  replies  from  an  R/R  are 
described  separately  in  Chapter  10  Section  10.3,  Section  10.4,  and  Section  10.7  for  each  of  the 
defined  control  port  types.  Each  R/R  must  support  at  least  one  of  the  control  port  types 
described  in  this  standard,  and  may  support  multiple  control  port  types. 


Table  6-3.  Command  Summary 

Command 

Parameters* 

Description 

M/O 

.CRITICAL 

[n  \maslc\  ] 

Specify  and  view  masks  that  determine 
which  of  the  .HEALTH  status  bits  are 
critical  warnings 

M 

.LILES 

[drive  ID] 

Displays  information  about  each  recorded 
file 

M 

.HEALTH 

[feature  [drive  ID]  ] 

Display  detailed  status  of  the  recorder 
system 

M 

.HELP 

Displays  table  of  dot  commands  supported 
by  the  R/R 

M 

.IRIG106 

Returns  supported  version  number  of 
IRIG-106  Recorder  Command  and 

Control  Mnemonics 

M 

.IRIG-I06 

Synonym  for  .IRIG106 

M 

.RECORD 

[filename]  [stream- 
ID]  [drive  ID] 

Starts  a  recording  at  the  current  end  of 
data  of  [stream  ID]  to  [drive  ID] 

M 

.SETUP 

[n] 

Displays  or  selects  1  of  16  (0. ..  15)  pre¬ 
programmed  data  recording  formats 

M 

.STATUS 

Displays  the  current  system  status 

M 

.STOP 

[mode]  [stream-ID] 
[drive  ID] 

Stops  the  current  recording,  playback,  or 
both 

M 

.TIME 

[start-time] 

Displays  or  sets  the  internal  system  time 

M 

.TMATS 

[mode]  [n  1  ALL] 

Write,  Read,  Save,  Delete,  Version, 
Checksum,  or  Get  TMATS  file 

M 

.ASSIGN 

[destination-channel 
ID]  [source-channel 
ID] 

Assign  replay  (output)  channels  to  source 
(input)  channels 

0 
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Table  6-3.  Command  Summary 

Command 

Parameters* 

Description 

M/O 

.BBLIST 

{type}  [drive  ID] 

Returns  list  of  secured  or  unsecured  bad 
blocks 

0 

.BBREAD 

(block  identifier] 
[drive  ID] 

Returns  contents  of  specified  block 

0 

•BBSECURE 

[block  identifier] 
[drive  ID] 

Marks  an  unsecured  bad  block  as  secure 

0 

.BIT 

Runs  all  of  the  built-in-tests 

0 

.CONEIG 

Retrieves  Channel  Configuration 

Summary 

0 

.COPY 

[source  drive  ID] 
[destination  drive 

ID] 

Copies  content  of  source  drive  to 
destination  drive 

0 

.DATE 

[start-date] 

Specify  setting  or  displaying  date  from 
recording  device 

0 

.DISMOUNT 

[drive  ID] 

Unloads  the  recording  drive 

0 

.DRIVE 

Eists  drives  and  volumes 

0 

.DUB 

[source  drive  ID] 
[destination  drive 

ID] 

Image  copy.  This  command  is  obsolete, 
but  for  backward  compatibility  shall 
function  the  same  as  the  .PEAY 
command. 

0 

.ERASE 

[drive  ID]  [volume 
name  list] 

Erases  and  format  the  recording  drive 

0 

.EVENT 

{event ID\ 

Insert  an  event  entry  or  display  captured 
events  list 

0 

.ETOEOOP 

[in  stream  ID]  [out 
stream  ID] 

Eooping  live  data  mode 

0 

.EIND 

[value  [mode]  ] 

Deprecated  (search  no  longer  required) 

0 

.EOOP 

[in  stream  ID]  [out 
stream  ID] 

Starts  record  and  play  in  read-after- write 
mode 

0 

.MEDIA 

[drive  ID] 

Displays  drive  usage  summary 

0 

.MOUNT 

[drive  ID] 

Powers  and  enables  the  recording  drive 

0 

.PAUSE 

[stream-ID] 

Pause  current  replay 

0 

.PEAY 

[location]  [speed] 
[drive  ID] 

Reproduce  recorded  data  of  assigned 
output  channels  starting  at  [location],  at 
[speed]  from  [drive  ID] 

0 

.PUBEISH 

[keyword] 

[parameter] 

Configure,  start  and  stop  live  data  over 
Ethernet 

0 

.PUBEISH_EIEE 

[parameter] 

[ip:port[  [file] 

[stream  ID] 

Configure,  start  and  stop  live  data  over 
Ethernet  interface  from  a  recorded 

Chapter  10  file 

0 

.PUBEISH TCP 

TBD 

TBD 

0 

.PUBEISH_CEG 

[keyword] 

Configures  filters  on  .PUBEISH  streams 

0 
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Table  6-3.  Command  Summary 

Command 

Parameters* 

Description 

M/O 

.OUT_CRATE 

[rate 

[EUEE  1  HASH]  ] 

Controls  the  rate  at  which  the 
configuration/  setup  record  (TMATS)  or 
checksum  of  same  should  be  output  to  the 
recording  stream 

0 

.QUEUE 

[keyword] 

[parameter] 

Specify  where  to  begin  replay  by  event  or 
file  number 

0 

.RCC- 106 

Synonym  for  .IRIG106 

0 

.REPEAT 

{location  [mode]  ] 

Same  as  PEAY 

0 

.RESET 

Perform  software  initiated  system  reset 

0 

.RESUME 

[stream-ID] 

Resume  replay  from  pause  condition 

0 

■SANITIZE 

[drive-ID] 

Secure  erases  the  recording  drive 

0 

.STREAM 

[#]  [stream-ID] 
[Channel-ID  Eist] 

Display  specified  or  all  stream  channel 
assignments 

0 

.TCPPORTS 

[n  1  n,n,n\ 

Displays  or  sets  network  characteristics 

0 

.VERBOSE 

[mode] 

Enables  Verbose  ON  or  disables  Verbose 

0 

.VOEUME 

Eists  volumes  on  current  drive 

0 

Parameters  in  braces  “{ }”  are  required.  Parameters  in  brackets  “[]”  are  optional.  When 
optional  parameters  are  nested  (“[xxx  [yy]]”),  the  outer  parameter  (xxx)  must  be  specified  in 
order  to  also  specify  the  inner  parameter  (yy).  Parameters  separated  by  a  vertical  bar  “1”  are 
mutually  exclusive  alternates. 

The  letters  in  parentheses  in  front  of  the  command  names  in  the  section  titles  below  represent 
mandatory  (M)  or  optional  (0)  commands. 

This  section  describes  the  protocol  for  implementing  Chapter  6  C&C  across  a  command 
line  interface  (CLI),  such  as  an  asynchronous  serial  communication  port.  Not  all  commands  may 
be  applicable  to  all  types  of  R/R  implementations.  An  important  aspect  of  the  CLI  C&C 
protocol  is  the  required  command-response  sequence.  For  each  command  issued  to  a  recorder, 
there  shall  be  exactly  one  response  from  the  R/R,  and  the  response  shall  begin  promptly  upon 
conclusion  of  the  command  input.  There  shall  be  no  delay  between  the  receipt  of  the  command 
at  the  recorder  and  the  transmission  of  the  reply  by  the  R/R.  The  reply  must  not  contain  any 
additional  line  feeds  or  carriage  returns.  Commands  that  initiate  operations  or  functions  that 
require  non-negligible  time  to  complete  shall  respond  immediately,  and  the  status  of  the  R/R 
may  be  polled  to  determine  when  the  operation  or  function  is  complete.  The  rate  at  which 
commands  may  be  issued  (i.e.,  the  minimum  interval  between  the  reply  to  one  command  and  the 
next  command)  is  defined  by  specification,  not  this  standard,  as  is  the  response  of  the  recorder  if 
the  rate  is  exceeded.  There  shall  be  no  unsolicited  status  output  from  the  R/R,  with  the  single 
exception  of  a  boot  message  upon  leaving  the  POWER  ON  state,  indicating  that  the  R/R  is  ready 
to  accept  commands.  The  boot  message  shall  contain  a  single  American  Standard  Code  for 
Information  Interchange  (ASCII)  asterisk  (“*”)  as  the  last  character.  Thereafter,  the  R/R  shall 
only  produce  output  in  response  to  a  command  input.  (A  hardware  reset  or  a  software  reset  shall 
return  the  recorder  to  the  POWER  ON  state.) 
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6.2.1  Command  Syntax  and  Rules 

All  CLI  commands  must  comply  with  the  following  syntax  and  rules. 

a.  All  R/R  commands  are  simple  ASCII  character  strings  delimited  by  spaces. 

b.  All  commands  begin  with  an  ASCII  period  (“.”)  and,  with  the  single  exception  of  the 
.TMATS  command,  end  with  the  first  occurrence  of  a  carriage  return  and  line  feed 
terminator  sequence. 

c.  Parameters  are  separated  from  the  commands  and  from  each  other  with  ASCII  space 
characters. 

d.  With  one  exception,  command  words  and  parameters  may  not  include  spaces.  The  one 
exception  is  the  [text  string]  parameter  for  the  .EVENT  command. 

e.  Multiple  consecutive  terminators  and  extraneous  space  characters  shall  not  be  allowed 
and  shall  be  ignored. 

f.  Each  command  is  followed  with  either  a  text  response  plus  a  carriage  return  and  line  feed 
and  an  asterisk  response  terminator  or  the  asterisk  response  terminator  only,  indicating 
the  recorder  is  ready  for  the  next  command. 

g.  A  response  shall  be  provided  by  the  R/R  within  one  second  of  the  command  completion 
sequence  (i.e.,  line  feed). 

h.  All  numeric  parameters,  with  one  exception,  are  decimal  numbers.  The  one  exception  is 
the  [mask]  parameter  for  the  . CRITIC AE  command,  which  is  hexadecimal. 

i.  Two  commands,  .EIND,  and  .REPEAY  have  numeric  parameters  requiring  units  of 
measure.  The  [mode]  parameter  is  used  to  specify  the  unit  of  measure  (time  or  blocks). 

If  the  [mode]  parameter  is  omitted,  the  recorder  shall  use  the  most  recently  entered 
[mode] . 

j.  A  [time]  parameter  value  has  five  parts:  days,  hours,  minutes,  seconds,  and  milliseconds. 
Any  part  not  entered  defaults  to  zero  except  days,  which  defaults  to  don’t  care  (current 
day).  An  ASCII  period  (“.”)  identifies  the  start  of  the  millisecond  part,  a  hyphen  (“-”) 
separates  the  day  from  the  hours,  and  colon  characters  (“:”)  separate  the  hours,  minutes, 
and  seconds.  The  following  are  valid  times:  123-  (day  only),  17  (hours  only),  17:30 
(hours  and  minutes),  17:30:05  (hours,  minutes,  seconds),  17:0:05  (hours,  minutes, 
seconds),  17:30:05.232  (hours,  minutes,  seconds,  milliseconds),  123-17  (day,  hours), 
123-17:30  (day,  hours,  minutes),  etc. 

k.  All  commands  begin  with  an  ASCII  period  and,  with  the  single  exception  of  the  .TMATS 
command,  end  with  a  carriage  return  and  line-feed  terminator  sequence. 

l.  Commands  are  case  insensitive  (i.e.,  they  may  be  upper  or  lower  case). 


6.2.2  Command  Error  Codes 

Issuing  invalid  commands  (bad  syntax)  or  illegal  commands  (not  accepted  in  the  current 
system  state)  results  in  error  code  responses  (with  an  ASCII  “E”  identifier)  prior  to  the  asterisk 
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response  terminator  when  a  command  cannot  be  completed.  Table  6-4  shows  possible  error 
codes  and  the  conditions  under  which  they  occur. 


y 

^  . RECORD 

E  03 

Example  f 

Means:  No  drive  is  installed,  recording  cannot  be 
executed 

Table  6-4.  Command  Error  Codes 

Error 

Description 

Conditions 

00 

INVAEID  COMMAND 

Command  does  not  exist 

01 

INVAEID  PARAMETER 

Parameter  is  out  of  range,  or  wrong  alpha-numeric  type 

02 

INVAEID  MODE 

Command  cannot  be  executed  in  the  current  state 

03 

NO  DRIVE 

Drive  is  dismounted  or  not  installed 

04 

DRIVE  EUEE 

Command  cannot  be  executed  because  there  is  no  free 
space  available  on  the  drive 

05 

COMMAND  EAIEED 

Command  failed  to  execute  for  any  reason  other  than 
those  listed  above 

06 

BUSY 

Command  cannot  be  executed 

6.2.3  Mandatory  Command  Descriptions 

Commands  are  listed  alphabetically. 


6.2.3. 1  (M)  .CRITICAL  {n{masm 

The  .CRITICAL  command  is  used  to  view  and  specify  the  critical  warning  masks  used 
with  the  .HEALTH  command.  An  encoded  32-bit  status  word  is  displayed  with  the  .HEALTH 
command  for  each  feature  as  defined  in  the  .HEALTH  command  in  the  R/R.  The  .CRITICAL 
command  allows  the  user  to  specify  which  status  word  bits  constitute  critical  warnings.  If  a  bit 
in  the  .CRITICAL  mask  word  for  a  feature  is  set,  then  the  corresponding  .HEALTH  status  word 
bit  for  that  feature  signals  a  critical  warning. 


The  .CRITICAL  command  without  any  parameters  returns  the  mask  word  for  each 
feature  in  ascending  feature  order.  The  .CRITICAL  command  with  a  single  parameter  -  the 
feature  number  -  returns  the  list  of  descriptive  warning  strings  and  status  word  bit  associations 
for  the  specified  feature.  The  .CRITICAL  command  with  both  the  feature  number  parameter  and 
the  8-character  ASCII  hexadecimal  mask  value  parameter  specifies  a  new  mask  value  for  the 
feature.  All  mask  values  in  the  command  responses  are  hexadecimal. 


NOTE 


y 


1 .  The  critical  warning  is  turning  the  EAULT  contact  output  indicator  ON 
for  a  Chapter  10-compatible  R/R. 

2.  Critical  warnings  of  individual  channels  should  not  inhibit  recording. 
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.CRITICAL 

J 

0 

FFFFFFFF 

SYSTEM 

Example  f 

1 

FFFFFFFF 

TIMEIN 

2 

OOOOOOFF 

ANAIN-1 

3 

0000006F 

PCMIN-1 

4 

OOOOOOOF 

PCMIN-2 

15 

00000010 

1553IN- 

Note:  The  eommand  with  no  parameters  returns  the  mask  for 
eaeh  feature  in  this  and  subsequent  examples. _ 


Example  / 

^  .CRITICAL  4 

4  00000004  PCMIN-2  Bad  Clock  Eailure 

4  00000008  PCMIN-2  Bad  Data  Eailure 

4  00000010  PCMIN-2  Minor  Erame  Sync  Eailure 

4  00000020  PCMIN-2  Major  Erame  Sync  Eailure 

* 

Note:  The  command  with  the  feature  number  parameter  only,  no 
mask  value,  returns  all  of  the  possible  warning  text  strings  for  the 
specified  feature  and  shows  which  .HEALTH  status  word  bit  is 
associated  with  the  particular  warning. 

y 

^  .CRITICAL  4  0000003C 

4  0000003C  PCMIN-2 

Example  f 

* 

Note:  Entering  both  the  feature  number  parameter  and  the  mask 
value  parameter  resets  the  mask  for  the  specified  feature. 

Note:  Entering  a  mask  of  0  for  the  feature  number  will  cause  the 
.HEALTH  command  to  denote  a  valid  state 

6.2.3.2  (M)  .FILES  [drive-ID] 

The  .FILES  command  displays  a  list  of  character  strings  showing  information  about  each 
recording  session  (file).  Each  string  in  the  list  contains  the  file  number,  file  name,  starting  block 
number,  file  size  in  bytes,  start  day,  and  start  time  of  the  file.  For  those  systems  that  also  store 
the  end  day  and  time  of  each  file,  that  data  may  be  added  to  the  end  of  each  file  string.  File 
names  may  not  contain  space  or  asterisk  characters.  If  user  names  are  not  assigned  to  individual 
recordings,  the  default  file  names  shall  be  “filel,”  “file2,”  etc.  Each  file  string  shall  be  formatted 
as  shown  in  the  following  example  (with  optional  end  day  and  end  time). 


.FILES 

/  1  TPD-10  10000 

272760832 

001-00:13:58.109 

001- 

_  ,  J  00:14:03.826 

Example  f  2  tpd-h  92884 

425984000 

001-00 : 14 : 11 . 106 

001- 

00:14:28.602 
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3  files  350790  305430528  123-17:44:06.677  123- 

17:44:13.415 


6.2.3.3  (M)  .HEALTH  [feature[dn\e-m]] 

The  .HEALTH  command  provides  a  standard  mechanism  for  status  information  to  be 
conveyed  to  the  user.  The  feature  parameter  is  defined  as  0  for  R/R  status,  and  for  each  data 
source  it  is  the  decimal  reference  of  the  channel  ID  specified  by  the  “TKl”  parameter  for  the 
corresponding  data  source  by  the  Telemetry  Attributes  Transfer  Standard  (TMATS)  setup  record. 
Entering  the  command  without  the  optional  parameter  displays  a  list  of  encoded  status  word  for 
each  feature.  Entering  a  decimal  feature  number  parameter  with  the  command  decodes  the  status 
word  for  a  single  feature  and  displays  a  list  of  messages  pertaining  to  the  feature,  one  for  each  set 
bit  in  the  status  word.  (See  Table  6-2  for  recommended  usage  of  the  status  bits.)  This  standard 
requires  that  the  syntax  of  the  responses  to  the  .HEALTH  command  conform  to  the  following 
rules. 

a.  If  no  data  sources  are  implemented,  the  response  to  a  .HEALTH  command  is  the  R/R 
status  only. 

b.  In  addition  to  the  feature  number  the  command  should  return  a  description  of  the 
corresponding  channel  type,  composed  from  the  channel  type  of  the  source  as  defined  in 
Chapter  9  parameter  “CDT”  -  a  character  and  the  sequence  number  of  that  type  of 
channel  (e.g.,  “PCMIN-3”  for  the  3“^  PCM  input  channel). 

c.  The  description  of  a  feature  may  not  contain  an  asterisk  character. 

d.  The  feature  list  response  (no  feature  number  parameter  supplied  with  the  command)  is  a 
sequence  of  text  strings,  each  containing  the  decimal  feature  number,  the  8-character 
ASCII  hexadecimal  representation  of  the  32-bit  status  word  for  the  feature,  a  text  feature 
description,  and  a  carriage  return  and  line  feed  terminator.  The  value  of  the  32-bit  status 
word  for  a  healthy  feature  shall  be  all  zeros.  If  a  feature  is  disabled,  the  8 -character 
ASCII  hexadecimal  string  shall  be  replaced  with  eight  ASCII  hyphen  characters. 

e.  The  individual  feature  response  (feature  number  parameter  supplied  with  the  command) 
is  a  sequence  of  descriptive  text  strings,  one  for  each  set  bit  in  the  feature  status  word. 
Each  string  is  terminated  with  a  carriage  return  and  line  feed. 

f.  The  critical  bits  should  be  cleared  when  they  are  reported  by  a  .HEALTH  command. 


The  .CRITICAL  command  is  used  to  specify  and  view  the  mask  word  for  each  feature 
that  determines  if  a  set  .HEALTH  status  word  bit  adds  to  the  total  non-critical  or  critical  warning 
counts  displayed  with  the  .STATUS  command. 


Example 


. HEALTH 


0 

00000000 

SYSTEM 

1 

00000000 

TIMEIN 

2 

00000000 

ANAIN-1 

3 

PCMIN-1 

4 

00000034 

PCMIN-2 

15 

00000000 

1553IN-8 
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★ 

/ 

HEALTH  4 

J 

4 

00000004 

PCMIN-2 

Bad  Clock  failure 

Example  f 

4 

00000010 

PCMIN-2 

Minor 

frame 

Failure 

4 

■k 

00000020 

PCMIN-2 

Major 

Frame 

Failure 

6.2.3.4  (M)  .HELP 

The  .HELP  command  displays  a  list  showing  a  summary  of  the  serial  "dot"  commands 
and  parameters  supported  by  the  R/R  as  listed  in  Table  6-3. 


Example 


.  HELP 

•ASSIGN  [ destination-ID ]  [source-ID] 

•BBLIST  {type} 

. BBREAD  {block  identifier} 

•BBSECURE  {block  identifier} 

•  BIT 

. CONE I G 

•COPY  [source  drive  ID]  [destination  drive  ID] 
•CRITICAL  [n  [mask]] 

•  DATE 


(full  list  from  Table  6-3 ) 
•TMATS  {mode}  [n|ALL] 


6.2.3.5  (M)  .IRIG106 

The  .IRIG106  command  returns  the  release  version  number  of  the  Chapter  6  R/R  C&C 
mnemonics  that  the  R/R  is  supporting.  Because  this  command  was  introduced  in  IRIG  106-07, 
R/Rs  supporting  earlier  releases  should  respond  with  the  invalid  command  error  message  (EOO). 
The  .IRIG-106  command  is  a  synonym  for  the  .IRIG106  command. 


Example 


. IRIG106 
7 

•k 

. IRIG-106 
7 


Note  :  This  example  indicates  that  the 
recorder  C&C  module  is  compatible 


with  IRIG  106-07 


6. 2. 3. 6  (M)  .RECORD  [filename]  [channel-group  ID]  [drive  ID] 

The  .RECORD  command  starts  a  new  recording.  The  optional  file  name  parameter  is  an 
ASCII  string  with  up  to  II  characters,  beginning  with  an  alphabetic  character,  and  with  no 
spaces  or  asterisks.  If  the  file  name  parameter  is  omitted,  the  filename  will  be  of  the  form 
“filen”,  where  n  is  the  file  number.  The  recording  will  continue  until  the  recording  drive  is  full 
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or  until  the  .STOP  command  is  issued.  The  optional  drive  ID  is  for  recorder  systems  with 
multiple  drives. 


Example 


.RECORD 

★ 


623.1  (M)  .SETUP  [n] 

The  .SETUP  command  chooses  one  of  16  pre-defined  setups  stored  in  the  R/R.  The 
optional  parameter  is  a  one-  or  two-digit  decimal  setup  number  from  0  to  15.  The  current  setup 
may  be  displayed  by  omitting  the  setup  number  parameter. 

The  .SETUP  command  shall  return  a  text  "RMM  [drive-ID]"  if  the  currently  applied 
setup  is  retrieved  from  the  removable  memory  module  (RMM). 

The  .SETUP  command  shall  return  a  text  "NONE"  if  the  currently  applied  setup  is  not 

saved. 


The  last  applied  setup  number  used  by  the  .SETUP  command  shall  be  stored  in  the  non¬ 
volatile  memory  of  the  R/R  and  automatically  used  as  the  default  setup  after  the  next  power 
cycle  of  the  R/R. 


6.2.3.8  (M)  .STATUS 

The  .STATUS  command  displays  the  current  state  of  the  R/R  and  two  counts.  The  first  is 
the  total  number  of  non-critical  warning  bits  currently  set  and  the  second  is  the  total  number  of 
critical  warning  bits  currently  set.  If  the  R/R  is  in  any  state  other  than  PAIL,  IDLE,  BUSY,  or 
ERROR,  the  command  also  displays  a  progress  percentage,  the  meaning  of  which  is  dependent 
on  the  specific  state.  Whenever  the  R/R  is  transitioning  between  states  and  the  transition  is  not 
instantaneous,  the  .STATUS  command  will  return  the  BUSY  state.  The  ERROR  state  is  entered 
when  the  currently  executing  command  does  not  complete  successfully.  Por  example,  when  a 
.PIND  command  is  unable  to  locate  the  specified  position  on  the  drive,  the  R/R  transitions  to  the 
ERROR  state.  Table  6-5  shows  the  various  states  by  numerical  code  and  describes  the  meaning 
of  the  progress  percentage  for  each  state.  An  ASCII  “S”  character  identifies  a  .STATUS 
command  response. 


Table  6-5.  Recorder  States 

State  Code 

State  Name 

Progress  Description 

00 

PAIL 

— 

01 

IDLE 

— 

02 

BIT 

Percent  complete 

03 

ERASE 

Percent  complete 
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04 

DECLASSIFY 

Percent  complete 

05 

RECORD 

Percent  media  recorded 

06 

PLAY 

Percent  recording  played 

07 

RECORD  &  PLAY 

Percent  media  recorded 

08 

FIND 

Percent  complete 

09 

BUSY 

— 

10 

ERROR 

— 

Example 


. STATUS 

S  03  0  0  84% 

★ 


. STATUS 

S  01  0  0 

★ 


6.2.3.9  (M)  .STOP  [mode]  [stream  ID]  [drive  ID] 

The  .STOP  command  stops  a  recording,  playback,  or  both.  The  optional  mode  parameter 
may  be  either  the  word  RECORD  or  the  word  PLAY.  If  the  optional  mode  parameter  is  not 
specified,  both  recording  and  playing  (or  either  of  the  two  modes  if  the  other  is  not  active)  will 
be  stopped.  Using  the  parameter  enables  either  recording  or  playing  to  be  stopped  without 
affecting  the  other,  when  both  are  active. 


Example 


.  STOP 
★ 


/S  07  0  0  26% 

* 

.STOP  PLAY 

r  * 

. STATUS 

S  05  0  0  26% 

The  current  state  can  be  displayed  with  the  status  command. 


^  . STATUS 

J 

S  01  0  0 

Example  f 

•k 

•  STOP 

E  02 

* 

The  .STOP  command  returns  an  error  if  the  R/R  is 

not  in  the  appropriate  state. 
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6.2.3.10  (M)  .TIME  [start-time] 

The  .TIME  command  displays  or  sets  the  internal  system’s  time.  The  optional  start-time 
parameter  is  formatted  as  shown  in  the  example  below.  Without  a  parameter,  this  command 
displays  the  current  system  time. 


/ 

.TIME 

TIME  001-23:59:59.123 

Example  / 

/ 

^  .TIME  123-13:01:35 

TIME  123-13:01:35.000 

Example  f 

* 

To  set  the  time,  enter  a  value  expressed  in  days, 
hours,  minutes,  seconds,  and  milliseconds. 

/ 

.TIME  123- 

TIME  123-00:00:00.000 

Example  / 

★ 

.TIME  15:31 

TIME  000-15:31:00.000 

Note:  Trailing  values  and  punctuation  may  be 
omitted  (zero  is  default). 

6.2.3.11  (M)  .TMATS  (mode)  [n] 

The  .TMATS  command  provides  a  vendor-independent  mechanism  for  loading  a  setup 
file  into  the  R/R  and  retrieving  a  setup  file  from  the  R/R.  The  required  mode  parameter  must  be 
one  of  the  following  seven  words:  WRITE,  READ,  SAVE,  GET,  DEEETE,  VERSION,  or 
CHECKSUM. 

Writing  or  reading  a  TMATS  file  transfers  the  file  between  the  external  host  and  the 
R/R’s  internal  volatile  memory  buffer.  Saving  or  getting  a  TMATS  file  transfers  the  file 
between  the  R/R’s  internal  volatile  memory  buffer  and  the  R/R’s  internal  non-volatile  setup  file 
storage  area.  To  store  a  new  setup  file  in  the  R/R,  the  .TMATS  WRITE  command  is  first  used  to 
transfer  the  file  to  the  recorder,  followed  by  a  .TMATS  SAVE  \n\  command  to  store  the  file  in 
non-volatile  memory.  The  numeric  setup  file  number  parameter  is  not  valid  with  the  .TMATS 
WRITE  command.  When  saving  the  file  to  non-volatile  memory,  the  optional  setup  file  number 
parameter  may  be  entered  to  designate  a  specific  setup  number  (see  the  .SETUP  command).  If 
the  setup  files  number  parameter  is  not  specified  with  the  .TMATS  SAVE  command,  the  file 
number  defaults  to  setup  0. 

a.  The  .TMATS  GET  \n\  command  performs  the  inverse  of  the  .TMATS  SAVE  command, 
retrieving  the  specified  or  default  (0)  file  from  non-volatile  to  volatile  memory  within  the 
R/R.  If  [n]  is  omitted,  it  shall  retrieve  the  active  TMATS. 
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b.  The  .TMATS  READ  command  transfers  the  file  currently  in  the  R/R’s  volatile  setup  file 
buffer  to  the  host. 

c.  Termination  of  the  .TMATS  WRITE  command  string  is  unique.  All  other  command  strings 
terminate  with  the  first  occurrence  of  a  carriage  return  and  line  feed  sequence.  The  .TMATS 
WRITE  command  string  does  not  terminate  until  the  occurrence  of  a  carriage  return  and  line 
feed  pair  followed  by  the  word  END  and  another  carriage  return  and  line  feed  pair. 

d.  The  .TMATS  DEEETE  mode  accepts  either  a  single  setup  number  [n]  or  the  keyword  AEE. 

e.  The  .TMATS  VERSION  command  returns  the  version  attribute  from  the  current  setup 
record. 

f.  The  .TMATS  CHECKSUM  \n\  command  returns  a  message  digest  of  the  entire  specified  or 
default  (0)  TMATS  record  excluding  only  the  G\SHA  code  name,  if  present.  The  message 
digest  shall  be  calculated  in  accordance  with  (lAW)  Eederal  Information  Processing 
Standards  Publication  180-4\  algorithm  “SHA-256.”  The  message  digest  is  a  string  of  64 
lower-case  hexadecimal  characters,  prefixed  with  the  constant  string  “2-”  to  designate  the 
algorithm.  If  the  TMATS  includes  a  G\SHA  code  name,  all  text  between  the  “G\SHA”  and 
the  following  semicolon,  inclusive,  shall  be  discarded  for  the  purposes  of  digest  calculation. 


^  . TMATS  WRITE 

J 

G\DSI\N=18; 

Example  f 

G\DSI-1 : TimelnChanl; 

G\DS 1-2 ; VoicelnChanl ; 

G\DSI-3: 1553Chan01; 

P-8\IDC8-1 : 0; 

P-8\ISF2-1 ; ID; 

P-8\IDC5-1 ;M; 

END 

■k 

The  .TMATS  WRITE  command  places  the  file  into 
the  volatile  buffer  of  the  R/R  and  applies  the  setup. 

Example 


.TMATS  READ 

G\DSI\N=18; 

G\DSI-1 :TimeInChanl; 
G\DSI-2 : VoicelnChanl; 
G\DSI-3 : 1553Chan01; 


P-8\IDC8-1 ; 0; 
P-8\ISF2-1 ; ID; 
P-8\IDC5-1 ;M; 


'  National  Institute  of  Standards  and  Technology.  “Secure  Hash  Standard  (SHS).”  FIPS  PUB  180-4.  August  2015. 
May  be  superseded  by  update.  Retrieved  25  April  2017.  Available  at 
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf. 
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The  .TMATS  READ  command  returns  the  file 
currently  in  the  volatile  buffer. 


J 

^  .TMATS  SAVE  3 
* 

Example  / 

The  .TMATS  SAVE  command  stores  the  file  in  the  volatile 
buffer  to  the  designated  non-volatile  file  memory  in  the  R/R. 

Example 


.TMATS  GET  3 

* 

The  .TMATS  GET  command  retrieves  the  designated  file  from 
non-volatile  file  memory  in  the  R/R  and  puts  it  in  a  buffer  that 
can  be  read  by  the  user.  The  retrieved  setup  will  also  be  applied. 


Example 


COMMENT:  *  G-Group  -  General  Information  *;  G\PN : TEST_XYZ ; 
G\TA:F16;  G\106:09;  G\OD : 10-22-2009; 

COMMENT:  Contact  information; 

G\POC\N: 1; 

G\POCl-l : Wile  E.  Coyote; 

G\POC2-l :ACME  Corp; 

G\POC3-l:123  Road  Runner  Way  Phoenix  AZ  99999;  G\POC4- 
1 : (555) 555-5555;  G\DSI\N:1;  G\DSI-1 : RF_DATA_SOURCE; 
G\SHA:0;  G\DST-1:RF;  G\SC:U; 


.TMATS  CHECKSUM  1 

2-3af058dc20fd35b82albebaf4de0ed6efa6e5e0ebefe8625494359180d8dl6c 

d 


The  .TMATS  CHECKSUM  [n]  command  returns  the  SHA-256  256-bit 
(32  bytes,  64  hexadecimal  characters)  message  digest  of  the  complete 
TMATS  file  stored  in  position  [n]  in  the  recorder. 

COMMENT:  *  G-Group  -  General  Information  *;  G\PN : TEST_XYZ; 
G\TA:F16;  G\106:09;  G\OD : 10-22-2009; 

COMMENT:  Contact  information; 

G\POC\N: 1; 

G\POCl-l : Wile  E.  Coyote; 

G\POC2-l :ACME  Corp; 

G\POC3-l:123  Road  Runner  Way  Phoenix  AZ  99999;  G\POC4- 
1 : (555) 555-5555;  G\DSI\N:1;  G\DSI-1 : RF_DATA_SOURCE;  G\SHA: 
2-3af058dc20fd35b82albebaf4de0ed6efa6e5e0ebefe862549435918 
0d8dl6cd;  G\DST-1:RF;  G\SC:U; 

.TMATS  CHECKSUM  1 

^  2-3af058dc20fd35b82albebaf4de0ed6efa6e5e0ebefe8625494359180d8dl6c 

d 

OiANGE  ,57 
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Note  the  addition  of  the  G\SHA  entry  does  not  alter  the  checksum. 


6.2.4  Optional  Command  Descriptions 

Commands  are  listed  alphabetically. 

6.2.4. 1  (O)  .ASSIGN  [destination-channel  ID]  [source-channel  ID] 

The  .ASSIGN  command  shall  be  used  for  assigning  output  channels  to  source  input 
channels.  The  source  IDs  are  composed  from  the  channel  type  of  the  source  as  defined  in 
Chapter  9  parameter  Command  Data  Type  -  a  character  and  the  sequence  number  of  that  type 
of  channel  (e.g.,  “PCMIN-3”  for  the  3'^‘^  PCM  input  channel).  The  destination  IDs  are  composed 
similarly  -  but  with  an  “OUT”  tag  in  the  Channel  Type,  instead  of  an  “IN”  tag.  Use  the  keyword 
“NONE”  in  place  of  source  ID  if  a  channel  is  to  be  unassigned.  The  command  with  the 
destination  ID  parameter  only  should  return  the  actually  assigned  source  ID;  without  any 
parameters  it  should  return  the  full  list  of  assignments. 

.ASSIGN  PCMOUT-6  PCMIN-2 

* 

Means:  PCM  input  channel  2  will  be  assigned  to  PCM  output 
- - r-—  f  channel  6 


J 

.ASSIGN  PCMOUT-6 

PCMM-2 

Example  f 

Means:  PCM  input  channel  2  is  currently  assigned  to  PCM  output 
channel  6 

/.ASSIGN  PCMOUT-1 
NONE 

■  ■  ■  r'  ■ /  Means:  No  channels  are  assigned  to  PCMOUT- 1 


6.2.4.2  (O)  .BBLIST  [type]  [drive-ID] 

A  .BBLIST  command  shall  be  utilized  to  return  the  unsecured  bad  block  identifiers  (any 
ASCII  text,  one  identifier  per  line)  from  the  drive.  A  .BBLIST  command  is  only  valid  following 
a  declassify  command.  The  type  shall  be  provided  indicating  which  type  of  bad  block  list  is  to 
be  returned.  If  type  =  “unsecured”,  .BBLIST  shall  return  a  list  of  unsecured  bad  blocks.  If  type 
=  “secured”,  .BBLIST  shall  return  a  list  of  secured  bad  blocks. 
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6. 2. 4. 3  (O)  .BBREAD  {block  identifier}  [drive-ID] 

A  .BBREAD  command  shall  be  utilized  to  return  the  raw  data  from  the  specified  bad 
block  in  ASCII  hexadecimal  format.  The  block  identifier  shall  be  provided  for  the  bad  block  to 
be  read. 


/ 

.BBREAD  5678 

00040000 

Example  / 

* 

6.2.4.4  (O)  .BBSECURE  (block  identifier)  [drive-ID] 

A  .BBSECURE  command  shall  be  utilized  to  mark  an  unsecured  bad  block  as  being 
secured.  A  block  that  has  been  identified  as  secured  shall  never  be  used  for  any  subsequent  data 
recording.  Secured  bad  blocks  shall  be  removed  from  an  unsecured  bad  block  identifier  list.  The 
block  identifier  shall  be  provided  for  the  block  to  be  secured. 


Example 


.BBSECURE  5678 
★ 


6.2.4.5  (O)  .BIT 

The  .BIT  command  runs  the  BIT  on  the  R/R.  The  prompt  is  returned  immediately  after 
the  test  is  started.  The  .BIT  command  is  only  valid  in  the  IDEE,  ERROR,  and  EAIE  states. 
During  the  BIT,  the  user  must  periodically  check  the  status  until  the  test  is  complete.  While  in 
BIT  mode,  the  percent  completion  is  shown  with  the  .STATUS  command.  The  result  of  the  .BIT 
command  is  go/no-go  status  indicated  by  the  end  state.  If  the  system  returns  to  the  IDEE  state, 
the  BIT  was  successful.  If  the  system  goes  to  the  EAIE  state,  the  BIT  failed  and  further  system- 
specific  diagnostics  are  required.  The  ASCII  “S”  in  the  response  is  the  identifier  of  a  .STATUS 
response. 


,  .BIT 

J 

* 

Example  f 

. STATUS 

S  02  0  0  21% 

* 

. STATUS 

S  02  0  0  74% 

* 

. STATUS 

S  01  0  0 

* 

6.2.4.6  (O)  .CONEIG 

This  command  retrieves  a  channel  configuration  summary  (vendor-defined  text  format). 
The  command  cannot  include  the  ASCII  character. 

6. 2. 4.7  (O)  .COPY  [source-drive-ID]  [destination-drive-ID] 

The  .COPY  command  can  be  used  for  copying  the  content  from  the  source  drive  to  the 
destination  drive. 
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6.2.4.8  (O)  .DATE  [start-date] 

The  .DATE  [start-date]  command  displays  or  sets  the  internal  system  date.  The  optional 
start-date  parameter  is  formatted  as  shown  in  the  example  below.  Without  a  parameter,  this 
command  displays  the  current  system  date.  The  timestamps  recorded  with  user  data  are  derived 
from  this  clock.  The  date  shall  be  set  in  year-month-day  format  according  to  ISO  8601. 


/ 

.DATE 

DATE  2002-12-31 

Example  / 

6.2.4.9  (O)  .DISMOUNT  [drive-ID] 

The  .DISMOUNT  command  disables  and,  if  necessary,  removes  power  from  the  active 
recording  drive.  The  drive  may  be  removed  only  after  this  command  is  issued. 


Example 


.DISMOUNT 

★ 


y 

.DISMOUNT 

^  E  03 

Example  f 

Note:  If  a  failure  occurs,  an  error  message  is 
displayed  before  the  prompt 

6.2.4.10  (O)  .DRIVE 

The  .DRIVE  command  gives  a  list  of  available  drives  and  volumes  defined  in  the  R/R 
setup  record. 


6.2.4.11  (O)  .DUB  [location] 

The  .DUB  command  is  identical  to  the  .PEAY  command,  except  that  it  specifies  the  use 
of  the  internal  playback  clock  to  retrieve  the  recorded  data. 


Example 


•  DUB 

★ 


6.2.4.12  (O)  .ERASE  [drive-ID]  [Volume  Name] 

The  .ERASE  command  logically  erases  all  data  on  the  drive,  allowing  for  recording  to 
begin  at  the  beginning  of  media. 

This  command  does  not  provide  assurance  that  the  device  is  in  any 
way  sanitized.  Data  may  still  be  recoverable. 
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The  prompt  is  returned  immediately  after  the  operation  is  started.  During  erase,  the  user 
must  periodically  check  the  status  until  the  operation  is  complete.  While  in  ERASE  state,  the 
percent  completion  is  shown  with  the  .STATUS  command. 


Example 


.ERASE 

* 

. STATUS 

S  03  0  0  23% 

★ 


. STATUS 

S  03  0  0  84% 

★ 


. STATUS 

S  01  0  0 

★ 


6.2.4.13  (O)  .EVENT  [event  ID] 

The  .EVENT  command  adds  an  event  entry  as  defined  in  the  recording  event  definitions 
within  the  setup  record.  An  event  command  is  defined  as  a  Recorder  “R”  event  type.  The  event 
ID  defined  in  the  setup  record  is  provided  with  the  command.  All  other  attributes  defined  with 
the  event  ID  are  applicable  so  that  the  command  result  is  an  event  packet  entry  for  the  given 
event  ID.  The  event  command  without  an  event  ID  shall  return  a  list  of  captured  events.  The  list 
shall  be  <list  #><event  IDxevent  time> 


Example 


.EVENT  5 

•k 


Example 


.EVENT 

1  005  00:13:58.109 

2  005  00:14:11.106 

3  005  01:01:06.677 


6.2.4.14  (O)  .ETOEEOOP  [instream- ID]  [outstream-ID] 

The  .ETOEEOOP  command  is  used  to  put  the  R/R  into  looping  live  data  mode.  Eive 
data  does  not  utilize  the  drive.  Data  is  moved  from  the  input  streams  directly  to  the  output 
streams.  The  output  data  rates  are  derived  from  the  data  rate  of  the  corresponding  input  stream. 
The  R/R  may  or  may  not  be  in  data  recording  mode. 

6.2.4.15  (O)  .EIND  [value  [mode]] 

The  .EIND  command  is  used  to  report  the  current  record-and-play  point  or  to  set  the  play 
point  to  the  desired  location  within  the  recorded  data.  The  desired  location  can  be  expressed  in  a 
number  of  different  formats  or  “modes:”  time  or  blocks.  When  the  command  is  entered  without 
any  parameters,  the  R/R  returns  the  current  record  point  and  current  play  points,  using  the 
current  default  mode.  The  default  mode  is  declared  each  time  a  mode  parameter  is  supplied  with 
the  .EIND  command  or  the  .REPEAY  command.  Thereafter,  the  mode  parameter  may  be 
omitted  and  the  R/R  will  use  the  default  mode.  The  mode  keywords  are  TIME  and  BEOCKS. 
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The  location  specified  in  the  value  parameter  of  the  .FIND  command  can  be  numeric  or 
one  of  six  keywords:  BOM  (beginning  of  media),  BOD  (beginning  of  data),  EOD  (end  of  data), 
EOM  (end  of  media),  BOE  (beginning  of  file),  and  EOE  (end  of  file).  These  keywords  may  be 
used  with  or  without  a  mode  parameter.  Numeric  location  values,  whether  accompanied  by  the 
mode  keyword  or  not,  must  be  valid  for  the  specified  or  default  mode.  Blocks  are  entered  as 
decimal  integer  numbers.  Time  is  entered  as  specified  in  Paragraph  6.2.1  itemj. 


6.2.4.16  (O)  .EOOP  [start/stop] 

The  .EOOP  command  is  used  to  either  start  read- after- write  mode  (which  begins 
recording  and  simultaneously  playing  back  the  recorded  data)  or  stop  read- after- write  mode.  The 
replayed  data  is  read  back  from  the  recording  drive.  If  the  R/R  is  already  recording  when  the 
.EOOP  command  is  issued,  the  command  starts  the  playback  at  the  current  record  point  without 
affecting  the  recording. 


Example 


. STATUS 

S  01  0  0 

* 

.LOOP 

★ 


. STATUS 

S  07  0  0  35% 

★ 


6.2.4.17  (O)  .MEDIA  [drive-ID] 

The  .MEDIA  command  displays  the  media  usage  summary.  It  shows  the  number  of 
bytes  per  block,  the  number  of  blocks  used,  and  the  number  of  blocks  remaining,  respectively. 
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/ 

.MEDIA 

MEDIA  32768  1065349  6756127 

Example  / 

-k 

6.2.4.18  (O)  .MOUNT  [drive-ID] 

The  .MOUNT  command  applies  power  and  enables  the  device  for  recording.  For 
systems  with  multiple  memory  canisters  or  media  cartridges,  the  effect  of  the  .MOUNT 
command  on  each  canister  or  media  cartridge  is  defined  in  advance  with  vendor-specific 
commands. 


Example 


.MOUNT 

★ 


6.2.4.19  (O)  .OUT_CRATE  [  rate  [type]  ] 

The  .OUT_CRATE  command  controls  the  output  rate  of  periodic  copies  of  the  currently 
active  configuration/setup  record  (TMATS)  or  the  checksum  of  the  currently  active 
configuration/setup  record.  Both  variants  (the  full  TMATS  record  or  the  checksum)  are  sent 
using  Computer-Generated  Data,  Eormat  4  packets  lAW  Chapter  1 1  Subsection  11.2.7.5;  note 
that  these  records  are  treated  like  any  other  packet  and  will  be  written  to  the  recording  media  as 
well  as  (potentially)  be  published. 

Both  variants  (full  and  checksum)  may  be  active  concurrently,  with  the  same  or  different 

rates. 

If  present,  the  rate  is  specified  in  seconds  and  indicates  the  desired  interval  between 
copies.  An  explicit  value  of  0  disables  the  production  of  the  copies.  This  standard  does  not 
dictate  the  set  of  acceptable  values  for  the  period,  but  in  the  event  that  an  implementation  cannot 
precisely  match  the  requested  period,  then  the  following  approach  shall  be  followed:  if  the  period 
requested  is  less  than  the  shortest  value  supported  by  the  implementation,  then  the  shortest 
implementation  value  shall  be  used;  otherwise  the  greatest  supported  value  less  than  or  equal  to 
the  requested  value  shall  be  selected. 

If  the  rate  is  omitted,  the  value  of  the  TMATS  R-x\HRATE-n  and  R-x\CRATE-n 
attribute  are  used,  depending  on  whether  the  “EUEE”  or  “HASH”  variant  is  selected  by  the  type 
parameter. 

If  the  type  parameter  is  omitted  or  is  specified  as  the  literal  text  “HASH”,  then  the 
checksum  of  the  active  setup  record  using  the  algorithm  defined  in  Subsection  6.2. 3. 11. f  is 
written  using  a  packet  lAW  Chapter  1 1  Subsection  1 1.2.7. 5;  if  “EUEE”  is  specified  then  the 
complete  text  of  the  TMATS  record  is  produced  lAW  Chapter  1 1  Subsection  1 1.2. 7. 5. 


6.2.4.20  (O)  .PAUSE  [stream-id] 

The  .PAUSE  command  stops  the  replay  operation.  If  parallel  recording  is  being 
performed,  it  continues.  If  no  play  position  is  moved  in  between,  the  .RESUME  command  can 
be  used  to  continue  replay.  The  .PAUSE  command  can  also  be  used  to  stop  only  the  replay 
while  the  recording  continues  (in  this  case,  a  new  replay  should  be  started  with  a  new  .PEAY 
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command).  If  the  stream  ID  is  present  it  will  pause  only  the  channels  defined  by  the  .STREAM 
command. 


Example 


. PAUSE 
★ 


6.2.4.21  (O)  .PLAY  {location]  [speed]  [drive  ID] 

The  .PLAY  command  starts  a  playback  of  the  data  at  either  the  current  play  point  or  at 
the  location  specified  in  the  optional  parameter  with  the  command.  The  current  play  point  is 
defined  to  be  the  drive  location  immediately  following  the  most  recently  played  data.  If  no 
.PLAY  command  has  been  issued  since  R/R  power-on,  the  current  play  point  is  the  beginning  of 
data.  The  location  parameter  has  two  forms:  [block_number]  and  [filename  [block_offset]].  If 
the  first  character  of  the  location  parameter  is  numeric,  the  entire  parameter  must  be  numeric, 
specifying  the  block  number  address  at  which  to  start  the  playback.  When  the  first  character  of 
the  location  parameter  is  alphabetic,  the  parameter  is  the  filename  to  play  back.  It  may  have  a 
second,  optional  parameter  specifying  the  numeric  0-origin  block  offset  into  the  named  file.  Use 
the  .LIND  command,  which  allows  positioning  the  play  point  wherever  necessary,  to  begin 
playing  at  a  location  other  than  a  block  number  or  file.  The  optional  [speed]  parameter  specifies 
the  replay  speed,  if  other  than  real-time  replay  speed  is  required.  The  syntax  of  the  speed 
specification  is:  *N  or  /N  (e.g.,  *5  for  5  times  faster,  /8  for  8  times  slower  replay). 

.PLAY  filel  250  0 
* 

Replay  from  the  current  position  4  times  faster  than  real-time 
speed: 

.PLAY  *4 
★ 


Example 


/ 


6.2.4.22  (O)  .PUBLISH  [keyword]  [parameter  list] 

The  .PUBLISH  command  shall  be  utilized  for  configuring,  starting,  and  stopping  UDP 
uni-,  multi-,  or  broadcast  of  live  data  in  Chapter  1 1  packet  format  over  any  IP  interface  to  the 
R/R.  The  following  keywords  are  allowed. 

.PUBLISH  START  IPaddressPortAddressstream-definition 

(Start  the  streaming  of  the  specified  stream  definition  to  the  destination  address.) 

If  a  new  list  is  defined  for  the  same  IP  address  and  PortAddress  combination,  this  will 
ADD  the  channels  of  the  new  stream  definition,  not  replace  them. 

.PUBLISH  STOP  stream-definition 

(Stop  streaming  of  the  specified  stream  definition.) 

The  IPaddressPortAddress  parameter  defines  the  destination  IP  address  and  the  port 
number  of  the  UDP  broadcast. 
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If  the  same  IP  address  and  PortAddress  combination  are  defined,  this  will  REMOVE  only 
the  listed  channels  of  the  stream  without  affecting  the  other  channels. 

The  stream-definition  parameter  can  be: 

A  stream  ID  previously  defined  using  the  .STREAM  command; 

A  channel  ID  list  as  defined  in  the  description  of  the  .STREAM  command. 

The  .PUBEISH  command  without  any  parameter  returns  the  streaming  channel  IDs  and  their 
destinations. 


Example 


.PUBLISH  START  192.145.255.255  1234  ALL 
* 

.PUBLISH  START  : : FFFF : C091 : FFFF  1234  ALL 
* 

.PUBLISH 

192.145.255.255  1234  ALL 

•k 


.PUBLISH  STOP  ALL 
* 

.PUBLISH  START  192.145.255.255  1234  1-12  18 
* 

.PUBLISH 

192.145.255.255  1234  1-12  18 

192.146.255.255  2345  13-17 

•k 


6.2.4.23  (O)  .PUBEISH_CEG  {keyword} 

The  .PUBEISH_CEG  command  sets  or  resets  modes  related  to  the  .PUBEISH  commands 
(including  the  .PUBEISH_TCP  variant).  By  default,  unless  otherwise  specified,  all  modes 
default  to  being  disabled.  Valid  keywords  are  shown  in  Table  6-6. 


Table  6-6.  PUBLISH_CFG  Keywords 

Enable  Keyword 

Disable  Keyword 

Description 

BEKEMTl 

NOBEKEMTl 

Controls  whether  Eormat  1  setup  records 
should  be  blocked  from  being  published. 

STREAMID 

NOSTREAMID 

Controls  reporting  currently  active  channels 
being  published. 

If  BEKEMTl  mode  is  set,  then  Computer-Generated  Data,  Eormat  1  packets  sent  on 
Channel  ID  0x0  (e.g.,  the  setup  record  required  to  be  the  first  packet  in  file  compliant  with 
Chapter  11)  will  be  blocked  and  not  sent  (published). 

If  STREAMID  mode  is  set,  then  a  Computer-Generated  Data,  Eormat  4  packet  lAW 
Chapter  1 1  Subsection  1 1.2. 7. 5  will  be  generated  when  the  channels  being  output  by  the 
.PUBEISH  command  change,  including  the  change  from  “not  PUBEISHING”  to 
“PUBEISHING”.  Note  that  the  channel  in  which  the  Eormat  4  packet  is  placed  (channel  0x0) 
must  be  included  in  the  active  stream  definition  for  the  change  packet  to  be  published. 
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6.2.4.24  (O)  .PUBLISH_FILE  [key word]  [parameter  list] 

The  .PUBLISH_FILE  command  shall  be  utilized  for  configuring,  starting,  and  stopping 
UDP  uni-,  multi-,  or  broadcast  of  recorded  data  from  a  medium  in  Chapter  1 1  packet  format  over 
any  IP  interface  of  the  R/R. 

.PUBLISH_FILE  START/STOP  IPaddressPortAddress  file-name  [start-time]  [stop-time] 
[speed]  stream-definition 

The  first  parameter  is  mandatory  and  must  be  either  START  or  STOP. 

The  IPaddressPortAddress  parameter  defines  the  destination  IP  address  and  the  port  number 
of  the  UDP  broadcast. 

The  optional  start- time  parameter  specifies  the  absolute  time  of  the  first  packet  to  be  sent  out 
from  the  file. 

The  optional  stop-time  parameter  specifies  the  absolute  time  of  the  last  packet  to  be  sent  out 
from  the  file. 

The  optional  speed  specifies  the  speed  of  the  UDP  broadcast.  It  can  be  one  of  the  following 
keywords: 

FUEE:  maximum  speed  the  R/R  and  media  are  capable; 

REAETIME:  near-real-time  streaming  -  as  close  as  possible  to  the  original  live  data 
streaming; 

MBPS  <n>:  with  a  specified  average  bit  rate  in  megabits  per  second. 

The  FileName  parameter  defines  the  file  to  be  sent  out  as  UDP  stream. 

The  stream-definition  parameter  can  be: 


A  stream-ID  defined  previously  in  the  .STREAM  command; 


A  channel-ID  list  as  defined  in  the  description  of  the  .STREAM  command. 


.PUBLISH_FILE  START  Filel.chlO  Stream2 


.PUBLISH_FILE  STOP  Filel.chlO 


Example 


.PUBLISH_FILE 

Filel.chlO  192.145.255.255  1234  1-12  18 


6.2.4.25  (O)  .PUBEISH_TCP  [key word]  [parameter  list] 

[TBD] 

6.2.4.26  (O)  .QUEUE  [keyword]  [parameter] 

The  .QUEUE  command  is  used  to  specify  a  recorded  data  file  or  defined  data  event  at 
which  to  begin  the  next  replay.  Replay  must  be  stopped  prior  to  issuing  the  .QUEUE  command. 
Keyword  options  are  either  event  or  file.  The  parameter  option  represents  either  the  event  or  file 
number  from  which  to  begin  replay. 
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6.2.4.27  (O).RCC-106 

The  .RCC- 106  command  is  a  synonym  for  the  .IRIG106  command 

6.2.4.28  (O)  .REPLAY  [location  [mode]] 

The  .REPLAY  command  initiates  a  repeated  playback  from  the  current  play  point  to  the 
end  point  specified  in  the  command,  using  an  internal  clock  to  “gate”  the  data.  The  syntax  of  the 
endpoint  parameter  is  identical  to  that  of  the  .LIND  command. 


6.2.4.29  (O)  .RESET 

The  .RESET  command  performs  a  software-initiated  reset  of  the  R/R,  returning  the  R/R 
to  the  power-on  state.  The  effect  shall  be  identical  to  a  power  cycle. 


Example 


. RESET 
* 


6.2.4.30  (O)  .RESUME  [stream-id] 

The  .RESUME  command  can  be  used  to  continue  the  replay  from  the  location  where  it 
was  stopped  by  the  .PAUSE  operation  -  with  the  replay  speed  specified  at  the  last  .PLAY 
command.  If  the  play  position  was  moved  with  the  .EIND  command  since  the  .PAUSE 
command  was  used,  the  replay  cannot  be  continued  by  the  .RESUME  command  -  a  new  .PLAY 
command  should  be  issued.  If  the  stream-id  is  present  it  will  pause  only  the  channels  defined  by 
the  .STREAM  command. 


Example 


.RESUME 

★ 


6.2.4.31  (O)  .SANITIZE  [drive-ID] 

The  .SANITIZE  command  erases  all  recorded  data  using  the  sanitization  procedure 
specific  to  that  recorder. 


This  command  will  permanently  erase  all  recorded  data.  Data  cannot  be 
recovered  once  this  command  has  been  executed!  Note  that  this 
command  makes  no  representation  that  any  given  recorder’s  sanitization 
procedure  is  appropriate  for  a  particular  application.  Rather,  if  the 
recorder  has  an  appropriate  procedure,  then  this  command  initiates  it. 


The  prompt  is  returned  immediately  after  the  operation  is  started.  During  sanitize,  the 
user  must  periodically  check  the  status  until  the  operation  is  complete.  While  in  the  SANITIZE 
state,  the  percent  completion  is  shown  with  the  .STATUS  command. 


Example 


.SANITIZE 

* 

. STATUS 

S  04  0  0  23% 

* 

. STATUS 
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S  04  0  0  84% 

* 

. STATUS 

S  01  0  0 

★ 


6.2.4.32  (O)  .STREAM  [stream  ID]  [channel  ID  list] 

The  .STREAM  command  displays  specified  or  all  stream  channel  assignments. 

6.2.4.33  (O)  .VERBOSE  [mode] 

The  .VERBOSE  command  enables  or  disables  verbose  mode  with  the  ON  or  OEE 
keywords. 

6.2.4.34  (O)  .VOEUME 

The  .VOEUME  command  gives  a  list  of  available  volumes  defined  in  the  TMATS. 

6.2.5  Command  Validity  Matrix 

Table  6-7  identifies  the  R/R  states  in  which  each  of  the  serial  commands  is  valid.  The 
legend  at  the  bottom  of  the  table  explains  the  matrix  entry  codes.  Two  codes,  3  and  4,  identify 
states  in  which  the  associated  command  may  or  may  not  be  valid  due  to  system-specific 
implementation.  The  R/R  users  should  assume  that  a  command  is  not  supported  in  a  system- 
specific  state  (code  3  or  4)  unless  the  specific  R/R’s  interface  control  document  assures  that 
support  is  provided. 


Table  6-7.  Command  Validity  Matrix 

Command 

State 

BUILT-IN 

TEST 

BUSY 

DECLASSIFY 

ERASE 

ERROR 

FAIL 

FIND 

IDLE 

PLAY 

POWER  ON 

RECORD 

RECORD  & 

PLAY 

.ASSIGN 

X 

X 

X 

X 

.BBEIST,  .BBREAD, 
.BBSECURE 

1 

.BIT 

X 

X 

X 

.CONEIG 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

.CRmCAE 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

.DATE 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

.DISMOUNT 

3 

3 

.DRIVE 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

.DUB 

X 

X 

X 

.ERASE 

X 

X 

.EVENT  (*) 

X 

X 

X 

X 

X 

X 

X 

X 

.EIEES 

X 

X 

X 

X 

X 

X 

X 

X 

.EIND 

X 

X 

X 
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.HEALTH 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

.HELP 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

.IRIG106 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

.LOOP 

X 

X 

X 

.MEDIA 

X 

X 

X 

X 

X 

X 

X 

X 

.MOUNT 

3 

3 

.PAUSE  (*) 

X 

X 

X 

.PLAY  (*) 

X 

X 

X 

.PUBLISH  (*) 

X 

X 

X 

X 

X 

.PUBLISH CLG 

X 

X 

.OUT CRATE 

X 

X 

X 

X 

X 

.QUEUE 

.RECORD  (*) 

X 

X 

X 

X 

.REPLAY 

X 

X 

X 

.RESET 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

.RESUME  (*) 

X 

X 

X 

.SANITIZE  (*) 

X 

X 

X 

.SETUP 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

.STATUS 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

.STOP 

X 

X 

X 

X 

.STREAM 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

.TIME 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

.TMATS 

X 

X 

.VOLUME 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Legend 

X  =  Always  valid. 

1  =  Only  valid  after  declassify  command  execution  has  completed. 

2  =  Query  function  always  valid.  Changing  masks,  setup,  or  time  only  valid  in  IDLE  or 

ERROR. 

3  =  MOUNT  and  DISMOUNT  only  valid  if  not  mounted  or  dismounted,  respectively. 

Commands  marked  (*)  may  have  implementation-specific  restrictions. 

6.2.6  Required  Command  Subset 

Table  6-8  identifies  the  minimum  subset  of  commands  that  must  be  implemented  for  each 
R/R  type  to  be  compliant  with  this  standard. 


Table  6-8.  Required  Commands 

Command 

Recorder  Type 

Tape 

Solid-State 

Disk 

.BIT 

M 

M 

M 

.CRITICAL 

M 

M 

M 

.DATE 

M 

M 

M 

.DECLASSIEY 

0 

M 

0 
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.DISMOUNT 

M 

M 

M 

.ERASE 

M 

M 

M 

.FILES 

0 

M 

M 

.HEALTH 

M 

M 

M 

.HELP 

M 

M 

M 

.IRIG106 

M 

M 

M 

.MEDIA 

M 

M 

M 

.MOUNT 

M 

M 

M 

.RECORD 

M 

M 

M 

.RESET 

M 

M 

M 

.SETUP 

M 

M 

M 

.STATUS 

M 

M 

M 

.STOP 

M 

M 

M 

.TIME 

M 

M 

M 

.TMATS 

M 

M 

M 

Legend 

M=  Mandatory  0  =  Optional 

6.3  MIL-STD-1553  Remote  Terminal  Command  and  Control 

As  of  RCC  106-17,  this  section  is  moved  to  Appendix  6- A. 

6.4  Discrete  Command  and  Control 

Any  R/R  that  implements  discrete  C&C  shall  implement  the  functions  described  herein. 
Required  discrete  control  functions  are  noted  in  Figure  6-9. 


Figure  6-9.  Required  Discrete  Control  Functions 


6.4.1  Control  and  Status  Lines 

Five  contacts  for  discrete  control  and  five  lines  for  indicating  status  shall  be  provided. 

All  the  lines  are  “active  low”:  grounding  a  control  line  (or  causing  the  indicator  line  to  go  to 
ground)  referenced  to  the  recorder’s  ground  activates  the  function  as  shown  in  Figure  6-10.  Note 
that  the  circuit  shown  in  Figure  6-10  is  for  reference  only,  and  specific  installations  may  require 
alternative  arrangements  that  are  beyond  the  scope  of  this  standard. 
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Figure  6-10.  Discrete  Control  and  Indicator  Functional  Diagram 


6. 4. 1.1  Activation 

All  control  inputs  are  activated  by  being  brought  to  0.55  volts  (V)  or  less.  Inputs  using 
momentary  switches  must  be  active  for  0.5  seconds  for  the  associated  command  to  be  invoked. 
All  status  outputs  are  set  to  be  “ON”  by  the  R/R  bringing  the  voltage  to  0.55  V  or  less.  The 
“OFF”  state  is  designated  by  the  output  being  open  circuit.  When  “ON”,  the  current  in  the 
circuit  shall  not  exceed  60  milliamps  (mA). 


6. 4. 1.2  Controls 

BIT  Command:  Activated  by  a  momentary  switch,  this  discrete  control  commands  the  recorder 
to  start  the  BIT  procedure. 

Enable  Command:  Activated  by  a  momentary  switch,  this  discrete  control  must  be  asserted 

simultaneously  with  either  the  ERASE  or  SANITIZE  discrete  for  that  control  to  operate. 

Erase  Command:  Activated  by  a  momentary  switch,  this  discrete  control  commands  the 

recorder  to  erase  its  user  data  and  file  directory  memory  provided  the  ENABEE  switch  is 
also  activated. 


Record  Command:  Activated  by  a  toggle  switch,  this  discrete  control  commands  the  recorder  to 
start  recording.  Recorder  will  remain  in  this  mode  for  the  duration  that  the  switch  is 
active  (i.e.,  closed). 

Sanitize  Command:  Activated  by  a  momentary  switch,  this  discrete  control  causes  the  recorder 
to  start  the  SANITIZE  procedure  provided  the  ENABEE  switch  is  also  activated. 


BIT  Status: 
Erase  Status: 
Fault  Status: 
Record  Status: 


The  built-in  test  is  running. 

The  media  is  erased  or  in  the  process  of  being  erased. 

The  R/R  is  not  ready  or  a  critical  warning  has  been  posted. 
The  R/R  is  recording. 
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Sanitize  Status:  The  media  is  sanitized  or  is  in  the  process  of  being  sanitized. 

6.4.2  Voltage 

28VDC  auxiliary  voltage  output  shall  be  provided  from  the  discrete/control  port  (250  mA 
max,  short  circuit  protection).  A  ground  reference  point  shall  be  provided. 

6.4.3  Status  Updates 

The  status  reflected  by  the  output  lines  shall  be  updated  to  match  the  actual  status  of  the 
R/R  at  least  once  every  2  seconds.  Whenever  a  status  is  activated  (“ON”),  it  shall  remain  ON  for 
a  minimum  interval  not  less  than  one  second;  status  lines  may  flash  (with  a  duty  cycle  of  500 
milliseconds  [ms]  ON,  500  ms  OFF)  to  indicate  that  the  R/R  is  in  the  process  of  accomplishing 
the  related  status.  Table  6-9  summarized  the  meanings  associated  with  each  status  line. 


Table  6-9.  Recorder/Reproducer  Status  Lines 

Status  Line 

On 

Flash 

Off 

ERASE 

Media  erased. 

Media  is  being 
erased. 

Media  is  not  erased. 

RECORD 

R/R  is  recording. 

- 

R/R  is  not  recording. 

EAUET 

R/R  is  not  ready,  or  any  of 
the  critical  warning  exists. 

R/R  is  running  properly. 

No  critical  warning. 

BIT 

Built-in  test  running. 

- 

Built-in  test  is  not  running. 

SANITIZE 

Media  sanitized. 

Media  sanitization 
is  in  progress. 

Media  is  not  sanitized. 

6.5  Commands  for  RMM  Devices 

CHANCE  ^ 

6.5.1  Mandatory  Commands 

The  mandatory  commands  for  all  RMM  devices  are  listed  in  Table  6-10.  Additional 
commands  that  are  mandatory  for  all  RMM  devices  that  support  declassification  are  listed  in 
Table  6-11.  Commands  that  are  mandatory  for  RMM  devices  that  support  the  Ethernet  host 
platform  interface  via  Telnet  are  listed  in  Table  6-12,  with  optional  Ethernet  commands  listed  in 
Table  6-13. 


Table  6-10.  Mandatory  Commands  (All  Interfaces) 

Command 

Parameters 

Description 

.BIT 

Runs  all  of  the  RMM  BITs. 

.CRITICAE 

[n  [mask]  ] 

Specifies  and  views  masks  that  determine  which  of  the 
.HEAETH  status  bits  are  critical  warnings. 

.DATE 

[start-date] 

Specifies  setting  or  displaying  date  from  RMM. 

.ERASE 

Erases  the  RMM  media. 

.HEAETH 

[feature] 

Displays  detailed  status  of  the  RMM. 

.IDENTIEY 

Queries  the  RMM  for  solid-state  memory  identification  and 
firmware  version. 
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Table  6-10.  Mandatory  Commands  (All  Interfaces) 

Command 

Parameters 

Description 

.INITIALIZE 

Initializes  RMM  internal  components. 

.IRIG106 

Retrieves  the  IRIG-106  supported  version  number. 

.MEDIA  P 

Queries  the  RMM  for  information  about  the  physical  media 
of  the  RMM  and  the  transfer  limits  for  the  required  physical 
input/output  (EO)  commands. 

.STATUS 

Displays  the  current  RMM  status. 

.TIME 

[start-time] 

Displays  or  sets  the  internal  system  time. 

Table  6-11.  Additional  Mandatory  Commands  for  Declassification 

Command 

Parameters 

Description 

.BBEIST 

Directs  the  RMM  to  retrieve  the  bad  block  list. 

.BBEIST  R 

Retrieves  the  bad  block  list  from  the  RMM. 

.BBREAD 

(block 

identifier] 

Returns  contents  of  specified  block  in  ASCII  hexadecimal  byte 
format. 

.BBREAD  P 

(block 

identifier] 

Directs  the  RMM  to  initiate  a  physical  block  read  of  the 
specified  physical  block  identifier. 

.BBREAD  D 

Retrieves  the  data  from  the  physical  block.  See  the  .MEDIA  P 
command  for  information.  Data  is  returned  in  binary  format. 

.BBSECURE 

(block 

identifier] 

Marks  an  unsecured  bad  block  as  secure. 

.DECEASSIEY 

Initiates  command  as  specified  by  user  specification  or  user 
CONOP  overwrite  procedures. 

.PB WRITE  P 

(block 

identifier] 

Directs  the  RMM  to  initiate  a  physical  block  write  of  the 
specified  physical  block  identifier. 

.PBWRITE  D 

Writes  the  data  to  the  physical  block  in  binary  format.  See  the 
.MEDIA  P  command  for  information. 

.SANITIZE 

Initiates  a  memory  clear  and  identification  of  bad  memory 
blocks. 

Table  6-12.  Additional  Mandatory  Commands  for  Ethernet  Interface 

Command 

Parameters 

Description 

.MEDIA  E 

Queries  the  RMM  about  which  protocols  it  supports. 

.RMMIP 

Displays  RMM  IP  address  and  associated  settings.  Mandatory 
only  with  Ethernet  host  platform  interface. 

.RMMIP 

keyword 

[parameter] 

Displays  and  controls  RMM  IP  addressing.  Mandatory  only 
with  Ethernet  host  platform  interface. 

.TIME 

[PTPSTATUSI 

PTP] 

Displays  and  controls  the  IEEE  1588  Precision  Time  Protocol 
(PTP)  (if  implemented). 

.TMATS 

GET 

Recovers  the  recorder  setup  configuration  file  (RSCE)  from  the 
RMM  storage. 

.TMATS 

READ 

Displays  the  RSCE. 
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Table  6-12.  Additional  Mandatory  Commands  for  Ethernet  Interface 

Command 

Parameters 

Description 

.TMATS 

SAVE  [n] 

Saves  the  RSCE  using  n  to  form  file  name. 

.TMATS 

WRITE 

Uploads  an  RSCE. 

Table  6-13.  Non-Mandatory  Commands  for  Ethernet  Interface 

Command 

Parameters 

Description 

.RMMERAME 

Displays  the  current  and  largest  maximum  frame  size. 

.RMMERAME 

Erame  size 

Sets  the  maximum  frame  size. 

.TCPPORTS 

Displays  a  comma-separated  list  of  the  TCP  port  numbers 
used  for  the  Telnet,  Pile  Transfer  Protocol  (PTP),  and  iSCSI 
services. 

.TCPPORTS 

portl,port2,port3 

Sets  the  ports  used  for  the  network  services. 

The  RMM  .HEALTH  command  response  is  presented  in  Table  6-14. 


Table  6-14. 

Removable  Memory  Module  .HEALTH  Command  Response 

Bit 

Mask 

Description 

RMM 

0 

01 

Bit  failure 

1 

02 

Setup  failure  (unable  to  set  the  time  or  date  properly) 

2 

04 

Operational  failure  (EO  error,  media  error,  etc.) 

3 

08 

Low  or  dead  battery  warning 

4 

10 

RMM  busy 

5 

20 

Reserved  for  future  Chapter  10  status  bit 

6 

40 

Reserved  for  future  Chapter  10  status  bit 

7 

80 

Reserved  for  future  Chapter  10  status  bit 

8-31 

Vendor- specific  health  status  bits 

6.5.2  Date  and  Time  Setting  Requirements 

To  set  time,  the  .TIME  commands  should  be  used  according  to  Subsection  6.2.3.10. 


6.5.2. 1  Time  Setting  Using  IEEE  1394b 

To  guarantee  avoiding  uncontrolled  delay,  the  following  algorithm  shall  be  used. 


a.  The  host  device  puts  a  .TIME  command  with  time  parameter  to  be  set  in  its  SEND  buffer 
and  sends  it  at  least  100  ms  prior  to  the  correct  time  to  the  real-time  clock  device.  The 
delay  is  necessary  to  allow  the  processor  device  to  be  prepared  for  the  exact  time  setting 
and  to  hold  off  enough  in  the  host  to  force  a  doorbell  with  the  next  SCSI  command. 
Without  enough  delay  the  host  will  not  be  able  to  chain  the  next  SCSI  command  together 
with  the  previous  command.  If  the  operating  system  demands  it  a  delay  greater  than  100 
ms  can  be  used. 
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b.  The  processor  device  shall  process  this  time  and  be  prepared  to  set  it  at  receipt  of  the 
doorbell. 

c.  A  .SEND  command  shall  be  sent  to  the  real-time  clock  with  the  message  .TIME  without 
parameters  to  query  for  the  time  as  set. 

6. 5. 2. 2  Time  Setting  using  Ethernet 

To  minimize  inaccuracy,  the  IEEE  1588  FTP  may  be  used.  How  an  RMM  derives  time 
from  PTP  is  not  controlled  by  the  standard.  The  .TIME  FTP  and  .TIME  PTPSTATUS  variants 
of  the  .TIME  command  shall  be  used  to  enable  and  view  the  status  of  the  PTP  implementation. 


6. 5. 2. 3  Date  Setting  Requirements 

A  .DATE  [start-date]  command  shall  be  utilized  for  setting  or  displaying  date  of  the 
removable  memory  real-time  clock.  The  date  shall  be  set  in  year-month-day  format  according  to 
ISO  Standard  8601:2004. 


Example 


.DATE 

DATE  2002-12-31 


6.5.3  Declassification  Supporting  Commands 

6.5.3. 1  .IDENTITY 

A  .IDENTIFY  command  queries  the  RMM  for  solid-state  disk  (SSD)  identification  and 
firmware  version. 

•  Description 

This  command  queries  the  RMM  for  SSD  identification  information  and  firmware 
version. 

•  Parameters 
None 

•  Response 

The  RMM  responds  with  one  line  containing  five  comma- separated  fields. 

Characters  and  spaces  are  allowed  within  the  comma- separated  fields.  Response  time 
shall  be  within  100  ms.  A  .STATUS  command  request  prior  to  100  ms  shall  elicit  a 
BUSY  response. 


* . IDENTIFY 

J 

A,  B, 

C,  D,  E 

Example  f 

* 

Where 

A  ... 

SSD  Manufacturer 

B  ... 

SSD  Model 

C  ... 

SSD  Serial  Number 
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D  .. 

RMM  Eirmware  Version 

E  ... 

SSD  Eirmware  Version 

6.5.3.2  .MEDIAE 

The  .MEDIA  P  command  is  utilized  to  query  the  RMM  for  information  regarding  the 
physical  block  architecture  of  the  SSD  and  the  SCSI  RECEIVE  transfer  limits  in  effect  when 
reading  physical  blocks. 


•  Parameters 


The  parameter  “P”  distinguishes  this  command  from  the  standard  .MEDIA  command. 


•  Response 


The  RMM  responds  with  one  line  containing  the  tag  “PHYSIC AE”  and  five  space- 
separated  integer  numbers.  Response  time  shall  be  within  100  ms.  A  .STATUS 
command  prior  to  100  ms  shall  return  a  BUSY  state. 


Example 


♦.MEDIA  P 

PHYSICAL  A  B  C  D  E 

* 


A  =  Physical  block  size  in  bytes.  This  value  must  be  a  multiple 
of  item  D  below. 

B  =  Total  number  of  physical  blocks  in  SSD. 

C  =  Maximum  operation  request  block  (ORB)  transfer  size  that 
can  be  used  when  reading  the  binary  data  from  the  physical 
block  with  the  .BBREAD  D  and  .PB WRITE  D  commands. 

D  =  Number  of  valid  data  bytes  in  a  physical  page.  Item  A 
above  must  be  an  integer  multiple  of  this  value. 

E  =  This  field  specifies  the  number  of  filler  bytes  appended 
onto  each  physical  page  read  from  the  RMM.  Eiller  bytes  are 
typically  inserted  to  pad  the  transfer  to  the  next  Advanced 
Technology  Attachment  sector  boundary.  If  no  padding  is 
required,  this  field  may  be  0. 


6.5.3.3  .SANITIZE 

A  .SANITIZE  command  shall  initiate  a  write/verify  of  all  RMM  user  data  physical 
blocks.  The  pattern  may  consist  of  either  all  EEs  or  all  00s.  The  .SANITIZE  command  shall 
identify  any  blocks  that  cannot  be  written  or  verified.  Blocks  that  cannot  be  written  to  or  contain 
at  least  one  bit  that  is  stuck  in  either  the  0  or  the  1  state  are  termed  bad  blocks.  The  user  shall 
review  the  block  contents  and  map  out  the  bad  blocks  such  that  they  are  no  longer  addressable. 
Once  the  address  has  been  mapped  out  the  blocks  are  no  longer  addressable  and  are  no  longer 
identified  in  the  bad  block  table  (Eigure  6-11). 
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•  Parameters 
None 

•  Response 

The  RMM  responds  with  an  asterisk.  Response  time  shall  be  within  100  ms.  A 
.STATUS  command  prior  to  100  ms  shall  elicit  a  BUSY  response.  During 
sanitization  the  RMM  shall  respond  with  “S  04  xx  yy  zz”;  where  zz  indicates 
percentage  complete.  Upon  completion  a  status  response  of  “S  1 1  xx  yy”  shall 
indicate  that  bad  blocks  were  found.  A  status  response  upon  completion  of  “S  12  xx 
yy”  shall  indicate  that  no  bad  blocks  were  found. 

*. SANITIZE 

* 

. 


6.5.3.4  .BBLIST 

A  .BBLIST  command  shall  be  utilized  to  instruct  the  RMM  to  retrieve  the  list  of 
unsecured  bad  block  identifiers  from  solid-state  media  residing  in  the  RMM.  A  .BBLIST 
command  is  only  valid  following  a  .SANITIZE  command. 


•  Parameters 
None 
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•  Response 


The  RMM  responds  with  an  asterisk.  Response  time  shall  be  within  100  ms.  A 
.STATUS  command  prior  to  100  ms  shall  return  a  BUSY  state. 


Example 


* .BBLIST 
★ 


6.5.3.5  .BBLIST  R 

A  .BBLIST  R  command  shall  be  used  to  retrieve  bad  block  identifiers  from  the  RMM. 
This  command  may  only  be  issued  immediately  following  a  successful  .BBLIST  command. 


•  Parameters 

The  parameter  “R”  distinguishes  this  command  from  the  standard  .BBLIST 
command. 


•  Response 


The  RMM  must  respond  with  a  list  of  hexadecimal  bad  block  identifiers.  Each 
identifier  must  be  terminated  with  a  <CR><LF>  sequence.  Each  identifier  must  be  a 
legal  hexadecimal  number  from  1  to  16  digits.  No  embedded  spaces  or  other  special 
characters  are  allowed.  Response  time  shall  be  within  100  ms.  A  .STATUS 
command  prior  to  100  ms  shall  return  a  BUSY  state. 


Example 


*. BBLIST  R 

000000E3 

0000034f 

FE0184C9 

★ 


6. 5. 3. 6  BBREAD  P  {block_identifier} 

A  .BBREAD  P  {block_identifier}  command  shall  direct  the  RMM  to  initiate  a  physical 
block  read  of  the  specified  physical  block  identifier. 


•  Parameters 


The  parameter  “P”  distinguishes  this  as  a  binary  physical  block  read  command. 

The  parameter  block_identifier  is  the  physical  block  identifier  from  the  BBEIST  R 
response  of  the  block  to  be  read. 


•  Response 


The  RMM  responds  with  an  asterisk.  Response  time  shall  be  within  100  ms.  A 
.STATUS  command  prior  to  100  ms  shall  return  a  BUSY  state. 


Example 


.BBREAD  P  FE0184C9 

■k 
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6.53.1  .BBREAD  D 

A  .BBREAD  D  command  shall  read  one  binary  physical  block  from  the  RMM.  This 
command  may  only  be  issued  immediately  after  a  suecessful  .BBREAD  P  command.  The 
physical  block  size,  page  size,  page  filler  size,  and  maximum  SCSI  receive  transfer  size  that  are 
required  to  perform  the  transfer  are  all  specified  in  the  RMM’s  response  to  the  .MEDIA  P 
command. 


•  Parameters 
None. 


Response 

The  RMM  responds  by  returning  the  requested  binary  physical  block  data.  Multiple 
SCSI  receive  commands  may  be  required  to  retrieve  the  entire  physical  data  block. 


Example 


*. BBREAD  D 

Response  is  in  binary. 


6. 5. 3. 8  .BBSECURE  {block  identifier} 

A  .BBSECURE  command  shall  be  utilized  to  mark  an  unsecured  bad  block  as  being 
secured.  A  block  that  has  been  identified  as  secured  shall  never  be  used  for  any  subsequent  data 
recording.  Secured  bad  blocks  shall  be  removed  from  the  unsecured  bad  block  identifier  list. 
The  bloek  identifier  shall  be  provided  for  the  block  to  be  secured. 

•  Parameters 


The  parameter  block_identifier  is  the  physical  block  identifier  from  the  .BBEIST  R 
response  of  the  block  to  be  seeured. 


•  Response 


The  RMM  responds  with  an  asterisk. 


Example 


.BBSECURE  5678 

•k 


6.5.3.9  .PBWRITE  P  (blockjdentifierj 

A  .PBWRITE  P  {block_identifier)  command  shall  direct  the  RMM  to  initiate  a  physical 
block  write  of  the  specified  physical  block  identifier. 

•  Parameters 

The  parameter  block_identifier  is  the  physical  block  identifier  from  the  BBEIST  R 
response  of  the  block  to  be  written. 

•  Response 

The  RMM  responds  with  an  asterisk.  Response  time  shall  be  within  100  ms.  A 
.STATUS  command  prior  to  100  ms  shall  return  a  BUSY  state. 


6-45 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  6,  July  2017 


/ 


.PBWRITE  P  FE0184C9 


Example  i 


6.5.3.10  .PBWRITE  D 

A  .PBWRITE  D  command  shall  write  one  binary  physical  block  to  the  RMM.  This 
command  may  only  be  issued  immediately  after  a  successful  .PBWRITE  P  command.  The  size 
of  the  physical  block  transfer  size  and  the  maximum  SCSI  send  page  size  required  to  perform  the 
transfer  are  all  specified  in  the  RMM’s  response  to  the  .MEDIA  P  command. 

•  Parameters 

Binary  data  block.  Multiple  SCSI  send  commands  may  be  required  to  transfer  the 
entire  physical  data  block. 

•  Response 


The  RMM  responds  with  an  asterisk  after  all  data  is  successfully  received. 


6.5.3.11  .INITIAEIZE 

A  .INITIAEIZE  command  shall  be  utilized  to  configure  the  RMM  memory  and  reset  of 
the  firmware. 

•  Parameters 


None 


•  Response 

The  RMM  responds  with  an  asterisk.  Response  time  shall  be  within  100  ms.  A 
.STATUS  command  prior  to  100  ms  shall  return  a  BUSY  state.  A  response  of  “SI 3 
XX  yy  zz”;  where  zz  indicates  percentage  complete  shall  be  provided.  Upon 
completion,  a  response  of  “S  14  xx  yy”  shall  be  provided;  where  yy  indicates  number 
of  seconds  required  after  initialization. 


* . INITIALIZE 


Example  i 


.  STATUS 


S  13  00  00  01% 


. STATUS 


S  13  00  00  02% 
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6.5.3.12  .DECLASSIFY 

A  .DECLASSIFY  command  shall  be  utilized  to  initiate  user  proeedures. 

•  Parameters 
None 

•  Response 

The  RMM  responds  with  an  asterisk.  Response  time  shall  be  within  100  ms.  A 
.STATUS  command  prior  to  100  ms  shall  return  a  BUSY  state.  During  sanitization 
the  RMM  shall  respond  with  “S  04  xx  yy  zz”;  where  zz  indieates  pereentage 
complete.  Upon  completion  a  status  response  of  “S  1 1  xx  yy”  shall  indicate  that  bad 
bloeks  were  found.  A  status  response  upon  completion  of  “S  12  xx  yy”  shall  indicate 
that  no  bad  blocks  were  found. 

* . DECLASSIFY 
* 

. 


6.5.3.13  .IRIG106 

A  .IRIG106  eommand  shall  be  utilized  to  retrieve  the  RCC  106-supported  version 
number. 

•  Parameters 
None 

•  Response 

The  RMM  responds  with  a  version  number  that  shall  be  a  two-integer  value 
representing  the  last  two  digits  of  the  year  of  RCC  106  release  supported  by  the 
device.  Response  time  shall  be  within  100  ms.  A  .STATUS  command  prior  to  100 
ms  shall  return  a  BUSY  state. 


J 

*.IRIG106 

09 

Example  f 

* 
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6.5.3.14  .STATUS 

A  .STATUS  command  shall  be  utilized  to  query  the  RMM  for  status  information  (see 
Table  6-15). 

•  Description 

This  command  queries  the  RMM  for  status  information. 

•  Parameters 
None 

•  Response 

The  RMM  response  to  a  .STATUS  command  is  of  the  form: 


y 

^  * . STATUS 

S  ABC 

[D%] 

Example  f 

'k 

Table  6-15.  Removable  Memory  Module  States 

State 

Description 

State 
Code (A) 

State 
Value  (B) 

State  Value  (C) 

Progress  Percentage 
(D) 

FAIL 

00 

IDLE 

01 

00 

00 

BIT 

02 

00 

00 

Percent  Complete 

ERASE 

03 

00 

00 

Percent  Complete 

DECEASSIEY 

SANITIZE 

04 

00 

00 

Pereent  Complete 

BUSY 

09 

00 

00 

SANITIZE 

COMPEETED 

BAD  BEOCKS 
EOUND 

11 

00 

Number  of  bad  blocks 
found  (Integer) 

SANITIZE 

COMPEETED  NO 
BAD  BEOCKS 
EOUND 

12 

00 

00 

INITIAEIZE  IN 
PROGRESS 

13 

00 

00 

Pereent  Complete 

INITIALIZE 

COMPEETE 

14 

00 

Number  of  seconds 
required  for 
initialization  (Integer) 
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6.5.3.15  RMM  Command  Error  Codes 

Issuing  invalid  commands  (bad  syntax)  or  illegal  commands  (not  accepted  in  the  current 
system  state)  results  in  error  code  responses  (with  an  ASCII  “E”  identifier)  prior  to  the  asterisk 
response  terminator  when  a  command  cannot  be  completed.  Table  6-16  shows  possible  error 
codes  and  the  conditions  under  which  they  occur. 


Table  6-16.  Command  Error  Codes 

Error 

Description 

Condition*s 

00 

INVAEID  COMMAND 

Command  does  not  exist 

01 

INVAEID  PARAMETER 

Parameter  is  out  of  range,  or  wrong  alpha-numeric  type 

02 

INVAEID  MODE 

Command  cannot  be  executed  in  the  current  state 

05 

COMMAND  EAIEED 

Command  failed  to  execute  for  any  reason  other  than 
those  listed  above 

y 

^  . CLEAR 

E  00 

Example  f 

6.5.4  SCSI  and  iSCSI  Commands. 

The  mandatory  SCSI  command  set  for  vendor-specific  devices  is  as  follows.  Note  that 
the  SCSI  standard  imposes  additional  requirements  for  a  device  to  be  compliant. 

a.  Eor  random-access  devices: 

INQUIRY 

READ 

READ  CAPACITY 
REQUEST  SENSE 
TEST  UNIT  READY 

b.  Eor  sequential-access  devices: 

INQUIRY 

READ 

REWIND 

TEST  UNIT  READY 
REQUEST  SENSE 

6.5.5  Mandatory  ORB  Formats  for  the  Processor  Device  Using  IEEE  1394b 

6 . 5 . 5 . 1  Minimum  Operational  Requirements 

The  time  setting  accuracy  of  the  real-time  clock  device  should  be  better  than  1  ms.  The 
short  time  accuracy  of  the  real-time  clock  device  must  be  better  than  10  parts  per  million  (ppm) 
in  the  temperature  range  0-40°C  and  better  than  50  ppm  in  the  temperature  range  -40°C  -  -i-85°C. 

6.5.5.2  IEEE  1394b  ORB  Eormat. 

a.  Eogin  ORB  format.  The  login  ORB  format  is  illustrated  in  Eigure  6-12. 
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Most  significant  bit  (msb)  Least  significant  bit  (Isb) 

3l~  30  29  28  27  24  23  20  19  16  15  0 

Password 


Login response 


n 

Rq fmt 

X 

Reserved 

Reconnect 

Function 

LUN 

password length 

login response length 

Status_FIFO 


Figure  6-12.  Login  ORB  Format 


•  Password.  In  this  32-bit  field,  the  password  shall  be  “RTC.”  The  password  field 
shall  contain  the  immediate  data  and  the  password_length  shall  be  zero. 

•  Login  response.  32  bits. 

•  login  response  length.  16  bits. 

o  The  Login_response  field  and  login_response_length  fields  shall  specify  the 
address  and  size  of  a  buffer  (minimum  of  12  bytes)  allocated  by  the  host  for 
the  return  of  the  login  response. 

•  n.  In  this  one-bit  field,  the  notify  bit  “n”  shall  be  one. 

•  Rq  fmt.  In  this  two-bit  field,  the  rq_fmt  shall  be  zero. 

•  X-  In  this  one-bit  field,  the  exclusive  bit  “x”  shall  be  one. 

•  Reserved.  A  four-bit  field.  Reserved  shall  be  zero. 

•  Reconnect.  The  four-bit  reconnect  field  shall  specify  the  reconnect  time  as  a  power 
of  2  seconds.  A  value  of  zero  shall  mean  one  second. 

•  Function.  This  field  is  four  bits.  The  function  shall  be  zero. 

•  LUN.  This  is  16  bits.  The  LUN  shall  be  one. 

•  Status  FIFO.  The  64-bit  Status_FIFO  shall  contain  the  address  allocated  by  the  host 
for  the  return  of  status  for  the  login  request  and  for  the  return  of  subsequent  write  and 
read  buffer  response(s)  indicating  success/failure  of  the  operation. 

b.  Login  Response.  The  login  response  format  is  illustrated  in  Figure  6-13. 


msb 

Isb 

31 

16 

15 

0 

Length 

login ID 

command block agent 

reserved 

reconnect_hold 

Figure  6-13.  Login  Response  Format 


•  Length.  This  16-bit  field  contains  the  length,  in  bytes,  of  the  login  response  data. 

•  login  ID.  This  16-bit  field  is  used  in  all  subsequent  requests  to  the  SCSI  multimedia 
command’s  management  agent. 
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•  command  block  agent.  This  is  a  64-bit  field  that  contains  the  base  address  of  the 
agent’s  control  and  status  register. 

•  Reserved.  This  16-bit  field  shall  be  zero. 

•  Reconnect  hold.  This  16-bit  field  is  to  be  defined. 

c.  Send.  The  send  command  ORB  format  is  illustrated  in  Figure  6-14,  and  the  send  data 
buffer  format  is  illustrated  in  Figure  6-15.  The  send  data  buffer  contains  the  send 
command  with  the  carriage  return,  line  feed,  and  binary  0  character  terminated. 
Alternatively,  a  .PB WRITE  D  command  will  send  data  in  binary  format. 


msb  Isb 

31  30  29  28  27  26  24  23  21  20  19  18  17  16  15  8  7  0 

next ORB 

data descriptor 

n  Rq fmt  r  d  Spd 

max payload  p  page size 

data  size 

OAh 

LUN  Res  AEN 

Xfer  Eng  -  upper  bits 

Xfer  Lng  -  lower  bits 

Control 

OOh 

OOh 

OOh 

OOh 

OOh 

OOh 

Figure  6-14.  Send  Command  ORB  Format 


Most  signilicant 


BMC  1 

BMC  2 

BMC  3 

BMe  4 

B\  te  5 

R\  te  6 

B\  te  7 

R\  te  8 

BMe  N-.3 

B\  te  N-2 

Bvte  N-1 

B\  te  N  B\  te 

Lca.st  significant 

Figure  6-15.  Send  Data  Buffer  Format 


•  next  ORB.  This  64-bit  field  contains  the  ORB  pointer  format,  which  shall  be  lAW 
SBP-2  specifications. 

•  data  descriptor.  The  32-bit  data_descriptor  field  shall  contain  the  address  of  the  data 
buffer. 

•  n.  The  completion  notification  “n”  in  this  one-bit  field  shall  be  one.  The  target  shall 
store  a  status  block  at  the  Status_FIFO  address  at  the  address  supplied  in  the  login 
request. 

•  Rq  fmt.  Required  format  in  this  two-bit  field  shall  be  zero. 

•  r.  Reserved  in  this  one-bit  field  shall  be  zero. 
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•  d.  Direction  bit  in  this  one-bit  field  shall  be  zero. 

•  spd.  This  is  a  three-bit  field  that  contains  speed,  which  shall  have  a  value  of  two. 

•  max  payload.  A  four-bit  field,  the  maximum  data  transfer  length  shall  be  nine. 

•  p.  This  is  a  one-bit  field.  The  RMM  must  be  prepared  to  handle  the  page  table  bit 
p=0  and  p=l  cases,  as  the  standard  operating  systems  set  this  bit  without  influence  of 
the  application  process. 

•  page  size.  This  is  three  bits.  Page  size  shall  be  zero  if  the  p  field  is  set  to  0; 
otherwise  this  field  shall  be  set  to  the  valid  page  size. 

•  data  size.  This  is  16  bits.  The  data  size  field  should  be  set  according  to  the  allocated 
send  buffer  size  in  bytes  (N).  The  length  must  be  at  least  80  (0x50). 

•  LUN.  The  LUN  shall  be  one  in  this  three-bit  field. 

•  Res.  This  is  a  four-bit  field.  Reserved  shall  be  zero. 

•  AEN.  In  this  one-bit  field,  AEN  shall  be  zero. 

•  Xfer  Eng.  This  is  24  bits.  The  length  must  be  at  least  80  (0x50). 

•  Control.  In  this  8-bit  field,  control  shall  be  128. 


d.  Receive.  The  receive  command  block  ORB  format  is  illustrated  in  Eigure  6-16. 


msb  Isb 

31  30  29  28  27  26  24  23  21  20  19  18  17  16  15  8  7  0 

next ORB 

data descriptor 

n  Rq fmt  r  d  spd 

max payload  p  page size 

data  size 

OAh 

EUN  Res  AEN 

Xfer  Eng  -  upper  bits 

Xfer  Eng  -  lower  bits 

Control 

OOh 

OOh 

OOh 

OOh 

OOh 

OOh 

Eigure  6-16.  Receive  Command  Block  ORB  Eormat 


•  next  ORB.  This  64-bit  field  contains  the  ORB  pointer  format,  which  shall  be  lAW 
SBP-2  specifications. 

•  data  descriptor.  The  32-bit  data_descriptor  field  shall  contain  the  address  of  the  data 
buffer. 

•  n.  The  completion  notification  “n”  in  this  one-bit  field  shall  be  one.  The  target  shall 
store  a  status  block  in  the  Status_PIPO  field  at  the  address  supplied  in  the  login 
request. 

•  Rq  fmt.  Required  format  in  this  two-bit  field  shall  be  zero. 

•  r.  Reserved  in  this  one-bit  field  shall  be  zero. 

•  d-  Direction  bit  in  this  one-bit  field  shall  be  zero. 

•  spd.  This  is  a  three-bit  field  that  contains  speed,  which  shall  have  a  value  of  two. 
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•  max  payload.  A  four-bit  field,  the  maximum  data  transfer  length  shall  be  nine. 

•  £.  This  is  a  one-bit  field.  The  RMM  must  be  prepared  to  handle  the  page  table  bit 
p=0  and  p=l  cases,  as  the  standard  operating  systems  set  this  bit  without  influence  of 
the  application  process. 

•  page  size.  This  is  three  bits.  Page  size  shall  be  zero  if  the  p  field  is  set  to  0; 
otherwise  this  field  shall  be  set  to  the  valid  page  size. 

•  data  size.  This  is  16  bits.  The  data  size  field  should  be  set  according  to  the  allocated 
send  buffer  size  in  bytes  (N).  The  length  must  be  at  least  80  (0x50). 

•  LUN.  The  LUN  shall  be  one  in  this  three-bit  field. 

•  Res.  This  is  a  four-bit  field.  Reserved  shall  be  zero. 

•  AEN.  In  this  one-bit  field,  AEN  shall  be  zero. 

•  Allocation  Eng.  This  is  24  bits.  Allocation_Eng  =  length  of  the  Chapter  6  response 
string. 

•  Control.  In  this  8-bit  field,  control  shall  be  128. 

The  receive  data  buffer  can  be  returned  in  ASCII  format  (see  Eigure  6-17)  or  in  binary 

format  (see  Eigure  6-18)  if  the  retrieved  data  contains  binary  information.  Multiple 

ORBs  may  be  used  to  retrieve  the  data  required. 
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Most  significant 


Hexadec.  10 

Length  Hish 

Length  Middle 

Length  Low 

Byte  1 

Byte  2 

Byte  3 

Byte  4 

• 

• 

• 

ByteN-3 

ByteN-2 

Byte  N-1 

ByteN 

Least  significant 

Figure  6-18.  Receive  Data  Buffer  Binary  Format 


•  The  returned  remote  answer  is  an  ASCII  text  terminated  by  the  character  lAW 
Section  62.  If  the  terminator  is  missing,  multiple  receive  commands  must  be 
used  to  retrieve  the  data  until  the  terminator  is  received. 

•  The  returned  remote  answer  can  contain  mixed  ASCII  text  or  binary  information  until 
the  specified  length  in  the  first  32-bit  word.  The  first  byte  is  a  hexadecimal  10  code 
to  identify  the  binary  format  (codes  hexadecimal  1 1-lF  are  reserved  for  future 
extensions).  The  answer  must  be  terminated  by  the  character  lAW  Subsection 
6.2.1.  If  the  terminator  is  missing,  multiple  receive  commands  must  be  used  to 
retrieve  the  data  until  the  terminator  is  received. 

6.5.6  Additional  Mandatory  Commands  When  Using  Ethernet 

6.5.6. 1  .MEDIAE 

The  .MEDIA  E  command  is  utilized  to  query  the  RMM  for  information  regarding  which 
of  the  data  access  protocols  is  supported. 

•  Parameters 

The  parameter  “E”  distinguishes  this  command  from  the  standard  .MEDIA  command. 

•  Response 

The  RMM  responds  with  one  line  containing  the  tag  “PROTOCOES”  and  at  least  one 
of  the  tags  “ETP”,  “ISCSI”,  and  “PTP”  in  alphabetical  order  each  separated  by  a 
space.  Response  time  shall  be  within  100  ms.  A  .STATUS  command  prior  to  100  ms 
may  return  a  BUSY  state. 

•  Example 

*. MEDIA  E 

PROTOCOES  ETP  PTP 

* 

6.5.6.2  .RMMIP 

The  .RMMIP  command  shall  be  utilized  to  display  RMM  IP  address  and  addressing 

mode. 
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•  Parameters 
None 

•  Response 

The  RMM  responds  with  one  line  containing  the  tag  “IP_ADDRESS”,  either  the  tag 
“STATIC”  or  “DHCP”,  and  three  space-separated  “dotted  quad”  IPv4  addresses, 
representing  the  IP  address  of  the  RMM,  the  net  mask  associated  with  that  address, 
and  the  default  gateway  for  the  network  associated  with  the  net  mask.  If  Dynamic 
Host  Control  Protocol  (DHCP)  is  being  used  and  no  DHCP  address  has  been 
obtained,  all  three  address  fields  shall  be  set  to  0. 0.0.0.  Response  time  shall  be  within 
100  ms.  A  .STATUS  command  prior  to  100  ms  may  return  a  BUSY  state. 

•  Examples 
*.RMMIP 

IP_ADDRESS  STATIC  10.6.9.2  255.0.0.0  10.6.9. 1 
*.RMMIP 

IP_ADDRESS  DHCP  192. 168.2. 1  255.255.255.0  192. 168.2.254 
*.RMMIP 

IP_ADDRESS  DHCP  O.O.O.O  O.O.O.O  O.O.O.O 

* 

6 . 5 . 6 . 3  .  RMMIP  keyword  [parameters  ] 

The  .RMMIP  command  shall  be  utilized  to  control  RMM  IP  address  and  addressing 

mode. 

•  Keywords 

DHCP  -  used  to  set  the  RMM  to  DHCP  mode. 

RESET  -  used  to  reset  the  Ethernet  RMM  to  defaults,  including  IP  addresses,  frame 
size,  and  login  passwords. 

xxx.xxx.xxx.xxx  -  used  to  set  the  RMM  to  static  mode  with  the  indicated  IPv4 
address;  requires  parameters,  “xxx”  indicates  any  number  between  0  and  255. 

•  Parameters 

NetMask  Gateway-  used  to  specify  the  net  mask  for  the  static  IP  address  and  the 
default  gateway  for  the  network  associated  with  the  net  mask.  Each  has  the  form 
xxx.xxx.xxx.xxx 

•  Response 

The  RMM  responds  with  an  asterisk.  Response  time  shall  be  within  100  ms.  A 
.STATUS  command  prior  to  100  ms  may  return  a  BUSY  state. 

•  Examples 
.RMMIP  DHCP 
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.RMMIP  RESET 

* 

.RMMIP  192.168.10.99  255.255.255.0  192.169.10.254 


6.5.6.4  .TIME  PTP 

A  .TIME  PTP  command  shall  be  used  to  initiate  the  proeess  of  synehronizing  the  RMM 
real-time  cloek  with  an  IEEE-1588  network  time  source.  Note  that  successful  synchronization 
with  a  time  source  will  implicitly  set  the  date  as  well  as  the  time. 

•  Parameters 

The  parameter  “PTP”  distinguishes  this  command  from  the  standard  .TIME 
command. 

•  Response 

The  RMM  responds  with  an  asterisk.  Response  time  shall  be  within  100  ms.  A 
.STATUS  eommand  prior  to  100  ms  may  return  a  BUSY  state. 

6.5.6.5  .TIME  PTPSTATUS 

A  .TIME  PTPSTATUS  command  shall  be  used  to  report  the  state  of  synchronization 
between  the  RMM  real-time  clock  and  an  IEEE- 1588  network  time  source. 

•  Parameters 

The  parameter  “PTPSTATUS”  distinguishes  this  command  from  the  standard  .TIME 
command. 

•  Response 

The  RMM  responds  with  one  line  containing  one  of  the  words  “EOCKED”  or 
“NONE”,  followed  by  an  asterisk  on  a  new  line.  “NONE”  indicates  that  no  sync  has 
been  obtained;  “EOCKED”  indieates  that  the  RMM’s  eloek  has  been  synehronized 
with  a  network  eloek.  Response  time  shall  be  within  100  ms.  A  .STATUS  command 
prior  to  100  ms  may  return  a  BUSY  state. 

6.5.6.6  .TMATS  GET 

A  .TMATS  GET  eommand  shall  be  used  to  transfer  the  eontents  of  the  RSCE  on  the 
RMM  media  into  a  volatile  buffer.  No  additional  parameter  is  required,  and  if  one  is  specified  it 
shall  be  ignored. 

•  Parameters 

The  parameter  “GET”  distinguishes  this  eommand  from  other  .TMATS  eommands. 

•  Response 

The  RMM  responds  with  an  asterisk.  If  no  valid  RSCE  lAW  Chapter  10  Subsection 
10.3.8.1  is  located  on  the  RMM  media,  an  error  is  returned  and  the  volatile  buffer  is 
erased.  A  .STATUS  eommand  prior  to  100  ms  may  return  a  BUSY  state. 
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6.5.6.7  .TMATS  READ 

A  .TMATS  READ  command  shall  be  used  to  display  the  contents  of  the  volatile  buffer 
created  by  either  a  .TMATS  GET  or  a  .TMATS  WRITE  command  for  the  RSCE. 

•  Parameters 

The  parameter  “READ”  distinguishes  this  command  from  other  .TMATS  commands. 

•  Response 

The  RMM  responds  by  displaying  the  contents  of  the  volatile  buffer  followed  by  a 
line  containing  an  asterisk.  If  the  buffer  contains  no  RSCE,  no  error  shall  be  returned. 

6.5.6.8  .TMATS  SAVE  n 

A  .TMATS  SAVE  command  shall  be  used  to  transfer  the  contents  of  the  volatile  buffer 
created  by  a  .TMATS  WRITE  command  to  the  media.  If  the  media  already  contains  any  data 
(except  for  a  previous  RSCE),  an  error  shall  be  returned.  The  created  file  shall  be  lAW  Chapter 
10  Subsection  10.3.8.1. 

•  Parameters 

The  parameter  “SAVE”  distinguishes  this  command  from  other  .TMATS  commands. 
The  number  following  is  used  to  generate  the  file  name  of  the  RSCE, 
“recorder_configuration_file_SAVE_n”. 

•  Response 

The  RMM  responds  with  an  asterisk.  A  .STATUS  command  prior  to  100  ms  may 
return  a  BUSY  state. 

6.5.6.9  .TMATS  WRITE 

A  .TMATS  WRITE  command  shall  be  used  to  transfer  a  TMATS  file  to  the  RMM  for 
subsequent  use  as  an  RSCE. 

•  Parameters 

The  parameter  “WRITE”  distinguishes  this  command  from  other  .TMATS 
commands. 

•  Response 

The  RMM  responds  by  entering  TMATS  data  transfer  mode.  All  data  sent  to  the 
RMM  will  be  added  to  a  volatile  buffer  until  a  line  with  the  single  word  “END”  is 
received,  following  which  the  RMM  responds  with  an  asterisk. 

6.5.7  Additional  Non-Mandatory  Commands  When  Using  Ethernet. 

6.5.7. 1  .RMMERAME 

The  .RMMERAME  command  shall  be  utilized  to  display  the  current  and  maximum 
values  for  the  Ethernet  frame  size  or  maximum  transmission  unit  (MTU). 

•  Parameters 
None 
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•  Response 

The  RMM  responds  with  one  line  containing  two  integers  separated  by  a  The 
first  integer  indicates  the  currently  configured  frame  size  (default:  1500  bytes),  and 
the  second  is  the  largest  frame  size  supported  by  the  RMM. 

•  Example 
*.RMMFRAME 
1500/9200 
*.RMMERAME 
1500/1500 
*.RMMERAME 
1300/9000 


An  RMM  command  error  code  of  00  (“Invalid  Command”)  shall  be 
interpreted  to  mean  that  the  default  value  of  1500  bytes  only  is  supported, 
and  thus  is  synonymous  with  a  response  of  “1500/1500”. 


6.5.12  .TCPPORTS  ffff 

A  .TCPPORTS  command  with  a  parameter  of  an  integer  shall  be  used  to  configure  the 
Ethernet  frame  size  or  MTU  to  be  used. 

•  Parameters 

ffff  where  ffff  is  the  value  to  be  used. 

•  Response 

The  RMM  responds  with  an  asterisk.  A  .STATUS  command  prior  to  100  ms  may 
return  a  BUSY  state. 

Once  the  RMM  has  responded,  all  devices  connecting  to  the  RMM  shall  adjust  their 
own  frame  size  settings  to  match  the  new  setting. 

•  Example 
*.RMMERAME  9000 

* 

6.5.7.3  .TCPPORTS 

The  .TCPPORTS  command  shall  be  utilized  to  display  the  port  numbers  used  for  the 
network  services  (Telnet,  FTP,  iSCSI). 

•  Parameters 
None 
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•  Response 

The  RMM  responds  with  one  line  containing  three  comma- separated  integers 
between  0  and  65535.  The  first  integer  indicates  the  port  at  which  the  Telnet  server  is 
listening,  the  next  is  the  port  used  by  the  FTP  server,  and  the  third  is  for  iSCSI.  If  an 
RMM  does  not  support  one  of  the  two  data  access  methods,  it  may  report  “0”. 

•  Example 
*.TCPPORTS 
923,921,3260 
*.TCPPORTS 
923,0,3260 


*.TCPPORTS 
928,921,  0 


NOTE^ 

Note:  a  response  of  “0,0,0”  or  an  RMM  command  error  code 

of  00  (“Invalid  Command”)  shall  be  interpreted  to  mean  that 

r 

the  default  ports  are  being  used,  and  thus  is  synonymous  with 

a  response  of  “923,921,3260”. 

6. 5. 7.4  .TCPPORTS  ppp,qqq,rrr 

A  .TCPPORTS  command  with  a  parameter  of  three  comma-separated  integers  between  0 
and  65535  shall  be  used  to  configure  TCP  ports  used  by  each  of  the  three  services  defined  for 
Ethernet  RMM  devices. 

•  Parameters 

ppp,qqq,rrr  where  ppp  is  the  port  to  be  used  for  the  Telnet  service,  qqq  is  the  port  to 
be  used  for  the  ETP  service,  and  rrr  is  the  port  to  be  used  for  iSCSI.  A  value  of  “0”  in 
any  one  of  the  positions  indicates  that  the  current  port  configuration  for  that  service  is 
not  to  be  changed. 

•  Response 

The  RMM  responds  with  an  asterisk.  A  .STATUS  command  prior  to  100  ms  may 
return  a  BUSY  state. 

If  the  port  for  the  Telnet  service  is  changed,  the  RMM  may  unilaterally  disconnect 
(close  the  Telnet  TCP  connection)  following  the  asterisk.  The  currently  configured 
Telnet  port  shall  be  accessible  by  means  of  the  Service  Eocation  Protocol  lAW 
Chapter  10  Subsection  10.9.3.2  item  c. 

•  Example 

*.TCPPORTS  923,921,3260 

* 
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APPENDIX  6-A 

MIL-STD-1553  Remote  Terminal  Command  and  Control 

The  MIL-STD-1553  implementation  of  Chapter  6  eommands  eomplies  with  typieal  bus 
controller  (BC)  operation.  Typically,  C&C  receive  messages  are  aperiodic  and  are  only  issued 
when  specific  R/R  action  is  required  by  the  BC.  The  C&C  transmit  messages  are  periodic  and 
report  status  back  to  the  BC. 

A.l.  Receive  Messages 


Table  A-1  provides  a  description  of  the  MIL-STD-1553  receive  commands  defined  in  the 
following  sections. 


Table  A-1.  Military  Standard  1553  Receive  (Bus  Controller  to  Remote 

Terminal)  Command  Set 

Command 

Subaddress 

Description 

ASSIGN 

1 

Selects  the  input  channel  to  be  replayed 

BIT 

1 

Runs  all  of  the  built-in  tests 

ERASE 

1 

Erases  the  recording  media 

EVENT 

1 

Marks  an  event 

INEO 

1 

Requests  detailed  information  regarding  a  specific  file  or 
event  (see  INEO  Transmit  Command  in  Table  A-2) 

PAUSE 

1 

Pauses  recording  of  all  or  specific  channels 

REPEAT 

1 

Controls  the  replay  of  recorded  data 

PUBEISH 

1 

Configures/controls  Ethernet  interface 

QUEUE 

1 

Sets  the  replay  point  in  the  recorded  data  to  a  file  or  event 

RECORD 

1 

Starts  a  recording  at  the  current  end  of  data 

RESET 

1 

Performs  software-initiated  system  reset 

RESUME 

1 

Resumes  recording  of  paused  channels 

SANITIZE 

1 

Secure-erases  the  recording  media 

STOP 

1 

Stops  the  current  recording,  playback,  or  both 

TIME 

1 

Sets  the  internal  system  time 

A. La.  Receive  Message  Length 

All  R1  (subaddress  1)  command  (receive)  messages  have  32  data  words.  All  unused  data 
words  are  zero-filled.  If  the  R/R  receives  an  improperly  formed  BC  to  remote  terminal  (RT) 
message  (length  error,  parity  error,  etc.)  it  will  respond  with  an  error  status  word  (the  last  word 
of  a  BC-to-RT  transaction)  and  the  message  will  be  ignored  by  the  R/R  control  program.  The 
acceptability  of  any  properly  formed  BC-to-RT  message  received  by  the  R/R  is  determined  by 
the  content  of  the  message  and  the  state  of  the  R/R  when  the  message  is  received,  as  identified  in 
this  standard.  The  R2  (subaddress  2)  command  (receive)  message  has  1  data  word. 
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A.l.b.  Assign  Command 

The  Assign  command  is  used  to  specify  the  desired  channel  for  replay  operations  (see 
Replay  command  below.) 


MESSAGE  NAME: 

Assign 

MESSAGE  ID: 

Rl-OOl 

TRANSEER  TYPE:  BC-RT 

SOURCE: 

BC 

WORD  COUNT:  32 

DESTINATION: 

R/R 

WORD  NAME 

WORD  NO. 

DESCRIPTION 

Command  Word 

CW 

Subaddress  00001  binary 

Assign  Command  ID 

01 

ID  of  Assign  command  =  0x0001 

Output  Channel  Number  02 

Output  Channel 

Input  Channel  Number  03 

Input  Channel  to  be  replayed 

Zero 

4-32 

Zero-filled 

Status  Word 

SW 

MIE-STD-1553  Status  Word 

WORD  NAME:  Assign  Command  ID 

WORD  ID: 

Rl-001-01 

RANGE:  N/A 

SOURCE: 

BC 

ACCURACY:  N/A 

DESTINATION: 

R/R 

Isb:  N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

1 

Hex  Digit  #1=0 

2 

3  Isb 

4  msb 

5 

f. 

Hex  Digit  #2  =  0 

1  Isb 

8  msb 

9 

Hex  Digit  #3  =  0 

10 

11  Isb 

12  msb 

13 

Hex  Digit  #4=1 

14 

15  Isb 

A-2 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  6,  July  2017 


WORD  NAME:  Output  Channel  Number 


WORD  ID: 

Rl-001-02 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0 

msb 

1 

Hex  Digit  #I 

2 

3 

Isb 

4 

msb 

5 

Hex  Digit  #2 

6 

7 

Isb 

8 

msb 

9 

Hex  Digit  #3 

10 

11 

Isb 

12 

msb 

13 

Hex  Digit  #4 

14 

15 

Isb 

WORD  NAME:  Input  Channel  Number 


WORD  ID: 

Rl-OOI-03 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 

0  msb  - 

1  Hex  Digit  #I 

2 

3  isb  - 

4  rnsb  - 

5  Hex  Digit  #2 
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6 


7 

Isb 

8 

msb 

9 

10 

11 

Isb 

Hex  Digit  #3 

12 

msb 

13 

14 

15 

Isb 

Hex  Digit  #4 

A.l.c. 

BIT  Command 

The  BIT  command  is  used  to  start  an  initiated  built-in  test  (IB IT).  While  in  the  BIT  state, 
the  percent  complete  is  output  via  the  STATUS  transmit  command.  When  the  IB  IT  completes, 
the  state  of  the  R/R  as  returned  by  the  STATUS  transmit  command  indicates  either  ‘TBIT  Pass” 
(state  =  IDLE)  or  “IB IT  Fail”  (state  =  FAIL).  Additional  failure  details  may  be  obtained  from 
the  HEALTH  transmit  command  response.  An  IB  IT  requires  no  more  than  10  seconds  to 
complete. 


MESSAGE  NAME:  BIT 

MESSAGE  ID:  Rl-002  TRANSFER  TYPE:  BC-RT 


SOURCE: 

BC  WORD  COUNT: 

32 

DESTINATION: 

R/R 

WORD  NAME 

WORD  NO. 

DESCRIPTION 

Command  Word 

CW 

Subaddress  00001  binary 

BIT  Command  ID 

01 

ID  of  Assign  command  =  0x0002 

Zero 

2-32 

Zero-filled 

Status  Word 

SW 

MIL-STD-1553  Status  Word 

WORD  NAME: 

BIT  Command  ID 

WORD  ID: 

R 1-002-01 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAL  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 

0  msb  - 
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I 

Hex  Digit  #1  =  0 

2 

3 

Isb 

4 

msb 

5 

Hex  Digit  #2  =  0 

6 

7 

Isb 

8 

msb 

9 

Hex  Digit  #3  =  0 

10 

II 

Isb 

12 

msb 

13 

Hex  Digit  #4  =  2 

14 

15 

Isb 

A.I.d. 

Erase  Command 

The  Erase  command  is  used  to  erase  internal  recording  drive  or  RMM  installed  in  the 
R/R.  While  in  the  Erase  state,  the  percent  complete  is  output  via  the  STATUS  transmit 
command. 


MESSAGE  NAME:  Erase 

MESSAGE  ID:  Rl-004  TRANSEER  TYPE:  BC-RT 


SOURCE: 

DESTINATION: 

WORD  NAME 

BC  WORD  COUNT: 
R/R 

WORD  NO. 

32 

DESCRIPTION 

Command  Word 

CW 

Subaddress  00001  binary 

Erase  Command  ID  01 

ID  of  Erase  command  =  0x0004 

Zero 

2-32 

Zero-filled 

Status  Word 

SW 

MIE-STD-1553  Status  Word 

WORD  NAME: 

Erase  Command  ID 

WORD  ID: 

R 1-004-0 1 

RANGE:  N/A 

SOURCE: 

BC 

ACCURACY:  N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 

0  msb  - 
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1 

Hex  Digit  #1  =  0 

2 

3 

Isb 

4 

msb 

5 

Hex  Digit  #2  =  0 

6 

7 

Isb 

8 

msb 

9 

Hex  Digit  #3  =  0 

10 

11 

Isb 

12 

msb 

13 

Hex  Digit  #4  =  4 

14 

15 

Isb 

A.l.e. 

Event  Command 

The  Event  command  is  used  to  mark  a  specific  event  occurrence  with  the  insertion  of  a 
Chapter  10  event  packet  in  the  recording  file.  The  BC  programmer  can  define  up  to  31  events 
numbered  1  to  3 1  in  the  TMATS  packet  that  is  loaded  into  the  recorder  from  the  RMM  and 
written  as  the  first  packet  in  each  data  file. 


MESSAGE  NAME: 

Event 

MESSAGE  ID: 

R 1-005  TRANSEER  ’ 

SOURCE: 

BC  WORD  COUNT: 

DESTINATION: 

R/R 

WORD  NAME 

WORD  NO. 

Command  Word 

CW 

Event  Command  ID 

01 

Event  Number 

02 

Zero 

3-32 

Status  Word 

SW 

WORD  NAME: 

Event  Command  ID 

WORD  ID: 

R 1-005-01 

SOURCE: 

BC 

DESTINATION: 

R/R 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

TYPE:  BC-RT 
32 


DESCRIPTION 
Subaddress  00001  binary 
ID  of  Event  command  =  0x0005 
1 -origin  number  of  a  defined  event 
Zero-filled 

MIE-STD-1553  Status  Word 


RANGE: 

N/A 

ACCURACY: 

N/A 

Isb: 

N/A 

BIT  NO. 


DESCRIPTION 
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0 

msb 

1 

Hex  Digit  #1  =  0 

2 

3 

Isb 

4 

msb 

5 

Hex  Digit  #2  =  0 

6 

7 

Isb 

8 

msb 

9 

Hex  Digit  #3  =  0 

10 

11 

Isb 

12 

msb 

13 

Hex  Digit  #4  =  5 

14 

15 

Isb 

WORD  NAME  Event  Number 


WORD  ID: 

R1 -005-02 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0  msb 

1 
2 

3  Isb 

4  msb 

5 

6 

7  Isb 

8 

9 

10 

11  msb 

12 

13 

14 

15  Isb 


Hex  Digit  #1  =  0 


Hex  Digit  #2  =  0 


Binary  0 
Binary  0 
Binary  0 


5 -bit  binary  event  number  from  1  to  N  where  N  is  the  number  of  defined 
BC  events  in  the  R/R  setup  record. 
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A.l.f.  Info  (receive)  Command 

The  Info  receive  command  is  used  to  specify  the  desired  information  to  be  returned  to  the 
BC  from  the  R/R  by  the  Info  transmit  command  (see  Paragraph  A.2.d). 


MESSAGE  NAME:  Info  (receive) 


MESSAGE  ID:  RI-007  TRANSEER 
SOURCE:  BC  WORD  COUNT: 

DESTINATION:  R/R 

WORD  NAME  WORD  NO. 

TYPE: 

32 

BC-RT 

DESCRIPTION 

Command  Word 

CW 

Subaddress  00001  binary 

Info  Command  ID 

01 

ID  of  Info  (receive)  command  =  0x0007 

Info  Type  and  Number 

02 

Info  type  and  file  or  event  number 

Info  Event  Occurrence 

03 

Specific  occurrence  when  type  =  event 

Zero 

4-32 

Zero-filled 

Status  Word 

SW 

MIL-STD-1553  Status  Word 

WORD  NAME:  Info  Command  ID 


WORD  ID: 

R 1-007-01 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 
XMIT  RATE 
SIGNAL  TYPE 
UNITS 

R/R 

Aperiodic 

Discrete 

N/A 

Isb: 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

1 

2 

Hex  Digit  #1=0 

3  Isb 

4  msb 

5 

6 

Hex  Digit  #2  =  0 

7  Isb 

8  msb 

9 

10 

Hex  Digit  #3  =  0 

11  Isb 

12  msb 

13 

14 

Hex  Digit  #4  =  7 

15  Isb 
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WORD  NAME 


Info  Type  and  Number 


WORD  ID: 

R1 -007-02 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 
SIGNAE  TYPE 
UNITS 


Aperiodic 

Discrete 

N/A 


BIT  NO. 


DESCRIPTION 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 


msb  Bit  0  is  the  Info  request  type:  0  =  file,  1  =  event 
Binary  0 
Binary  0 
Binary  0 
Binary  0 
Binary  0 

Bit  6  -  15  is  the  unsigned  binary  integer  file  number 
when  Bit  0  =  0  or  the  unsigned  binary  integer 
event  number  when  Bit  0=1.  Bit  6  is  the  msb 
and  Bit  15  is  the  Isb 


Isb 


WORD  NAME:  Info  Event  Occurrence 


WORD  ID: 

R1 -007-03 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 


DESCRIPTION 


0  msb 
1 
2 

3 

4 

5 


Bit  0  -  15  is  the  unsigned  integer  event  occurrence  number  of 
the  event  specified  in  data  word  2  bits  6-15  when  Bit  0  of  data 
word  2=1,  otherwise  this  data  word  3  is  unused  (zero)  when 
Bit  0  of  data  word  2  =  0.  Bit  0  is  the  msb  and  Bit  15  is  the  Isb 
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6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


A.l.g.  Pause  Command 

The  Pause  command  is  used  to  instruct  the  R/R  to  suspend  recording  of  one  or  more 
channels,  either  by  channel  type  or  specific  channel  IDs. 


MESSAGE  NAME:  Pause 


MESSAGE  ID:  Rl-008  TRANSEER  TYPE:  BC-RT 
SOURCE:  BC  WORD  COUNT:  32 

DESTINATION:  R/R 


WORD  NAME 

WORD  NO. 

DESCRIPTION 

Command  Word 

CW 

Subaddress  00001  binary 

Pause  Command  ID 

01 

ID  of  Pause  command  =  0x0008 

Pause  Condition 

02 

Channel  group  or  individual  channels 

Pause  Channel  ID 

03-16 

Individual  Channel  ID  or  zero 

Zero 

17-32 

Zero-filled 

Status  Word 

SW 

MIE-STD-1553  Status  Word 

WORD  NAME: 

Pause  Command  ID 

WORD  ID: 

Rl-008-01 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb  - 

1  Hex  Digit  #1  =  0 

2 

3  isb  - 
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4  msb 

5 

6 

7  Isb 

8  msb 

9 

10 

11  Isb 

12  msb 

13 

14 

15  Isb 


Hex  Digit  #2  =  0 


Hex  Digit  #3  =  0 


Hex  Digit  #4  =  8 


WORD  NAME:  Pause  Condition 


WORD  ID: 

R1 -008-02 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0  msb 


Bit  No. 


4 

5 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


Binary  0 

Bits  1-3  are  a  three-bit  code  that  specify  the  type  of  pause 
123 

000  =  Individual  Channel(s) 

001  =  All  Channels 

Remaining  bits  reserved 

Binary  0 
Binary  0 
Binary  0 
Binary  0 
Binary  0 
Binary  0 
Binary  0 
Binary  0 
Binary  0 
Binary  0 
Binary  0 
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WORD  NAME: 

WORD  ID: 
SOURCE: 
DESTINATION: 
XMIT  RATE 
SIGNAE  TYPE 
UNITS 

BIT  NO. 

0  msb 
1 
2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


A.l.h.  Queue  Command 

The  Queue  command  is  used  to  specify  a  recorded  data  file  or  defined  data  event  at 
which  to  begin  the  next  replay.  Replay  must  be  stopped  prior  to  issuing  the  Queue  command. 


Pause  Channel  ID 


Rl-008-03toRl-008-16 

RANGE: 

N/A 

BC 

ACCURACY: 

N/A 

R/R 

Isb: 

N/A 

Aperiodic 

Discrete 

N/A 


DESCRIPTION 

Bit  0  -  15  is  the  unsigned  integer  Channel  ID  number  of  a 
channel  to  be  paused  when  Bits  1-3  of  data  word  2  equal  110, 
otherwise  these  data  words  3  to  16  are  unused  and  zero-filled. 


MESSAGE  NAME:  Queue 


MESSAGE  ID:  Rl-011  TRANSEER  TYPE: 
SOURCE:  BC  WORD  COUNT:  32 

DESTINATION:  R/R 

WORD  NAME  WORD  NO. 

BC-RT 

DESCRIPTION 

Command  Word 

CW 

Subaddress  00001  binary 

Queue  Command  ID 

01 

ID  of  Queue  command  =  OxOOOB 

Queue  Mode/Number 

02 

Queue  type  and  file  or  event  number 

Queue  Event  Occurrence 

03 

Specific  occurrence  when  type  =  event 

Zero 

4-32 

Zero-filled 

Status  Word 

SW 

MIE-STD-1553  Status  Word 
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WORD  NAME:  Queue  Command  ID 


WORD  ID: 

Rl-011-01 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0 

msb 

1 

Hex  Digit  #1  =  0 

2 

3 

Isb 

4 

msb 

5 

Hex  Digit  #2  =  0 

6 

7 

Isb 

8 

msb 

9 

Hex  Digit  #3  =  0 

10 

11 

Isb 

12 

msb 

13 

Hex  Digit  #4  =  B 

14 

15 

Isb 

WORD  NAME:  Queue  Mode/Number 


WORD  ID: 

Rl-011-02 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 


DESCRIPTION 


0 

1 

2 

3 

4 


msb  Bit  0  is  the  Queue  request  type:  0  =  file,  1  =  event 
Binary  0 
Binary  0 
Binary  0 
Binary  0 
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5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 


Binary  0 

Bit  6  -  15  is  the  unsigned  binary  integer  file  number 
when  Bit  0  =  0  or  the  unsigned  binary  integer 
event  number  when  Bit  0=1.  Bit  6  is  the  msb 
and  Bit  15  is  the  Isb 


Isb 


WORD  NAME: 

WORD  ID: 
SOURCE: 
DESTINATION: 
XMIT  RATE 
SIGNAE  TYPE 
UNITS 

BIT  NO. 

0  msb 
1 
2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


A.l.i.  Record  Command 

The  Record  command  is  used  to  open  a  new  file  in  the  R/R  internal  memory  or  RMM  file 
table  and  start  recording  data.  While  in  the  Record  state  or  Record  and  Play  state,  the  percent  of 
drive  filled  (total  minus  remaining)  is  output  via  the  STATUS  transmit  command. 


Queue  Event  Occurrence 


Rl-011-03 

RANGE: 

N/A 

BC 

ACCURACY: 

N/A 

R/R 

Isb: 

N/A 

Aperiodic 

Discrete 

N/A 

DESCRIPTION 

Bit  0  -  15  is  the  unsigned  integer  event  occurrence  number  of 
the  event  specified  in  data  word  2  bits  6-15  when  Bit  0  of  data 
word  2=1,  otherwise  this  data  word  3  is  unused  (zero)  when 
Bit  0  of  data  word  2  =  0.  Bit  0  is  the  msb  and  Bit  15  is  the  Isb 
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MESSAGE  NAME:  Record 


MESSAGE  ID: 

SOURCE: 

DESTINATION: 

WORD  NAME 

Rl-012  TRANSEER  TYPE:  BC-RT 

BC  WORD  COUNT:  32 

R/R 

WORD  NO.  DESCRIPTION 

Command  Word 

CW 

Subaddress  00001  binary 

Record  Command  ID  01 

ID  of  Record  command  =  OxOOOC 

Zero 

02-32 

Zero-filled 

Status  Word 

SW 

MIE-STD-1553  Status  Word 

WORD  NAME: 

Record  Command  ID 

WORD  ID: 

R1-012-0I 

RANGE:  N/A 

SOURCE: 

BC 

ACCURACY:  N/A 

DESTINATION: 

R/R 

isb:  N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

I 

Hex  Digit  #1=0 

2 

3  Isb 

4  msb 

5 

Hex  Digit  #2  =  0 

6 

7  Isb 

8  msb 

9 

Hex  Digit  #3  =  0 

10 

11  Isb 

12  msb 

13 

Hex  Digit  #4  =  C 

14 

15  Isb 

A.Ej.  Replay  Command 

The  Replay  command  is  used  to  start,  pause,  continue,  and  control  the  speed  of  replay  of 
the  recorded  data. 
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MESSAGE  NAME:  Replay 


MESSAGE  ID:  Rl-009  TRANSEER  TYPE:  BC-RT 
SOURCE:  BC  WORD  COUNT:  32 

DESTINATION:  R/R 


WORD  NAME 

WORD  NO. 

DESCRIPTION 

Command  Word 

CW 

Subaddress  00001  binary 

Replay  Command  ID 

01 

ID  of  Replay  command  =  0x0009 

Replay  Type/Speed 

02 

Start/continue  and  speed  control 

Replay  Time  Word  1 

03 

Start  time  seconds/milliseconds 

Replay  Time  Word  2 

04 

Start  time  hours/minutes 

Replay  Time  Word  3 

05 

Start  time  month/days 

Replay  Time  Word  4 

06 

Start  time  year 

Zero 

07-32 

Zero-filled 

Status  Word 

SW 

MIE-STD-1553  Status  Word 

WORD  NAME:  Replay  Command  ID 


WORD  ID: 

R 1-009-01 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 
XMIT  RATE 
SIGNAE  TYPE 
UNITS 

R/R 

Aperiodic 

Discrete 

N/A 

isb: 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

1 

2 

Hex  Digit  #1=0 

3  Isb 

4  msb 

5 

6 

Hex  Digit  #2  =  0 

7  Isb 

8  msb 

9 

10 

Hex  Digit  #3  =  0 

11  Isb 

12  msb 

13 

14 

Hex  Digit  #4  =  9 

15  Isb 
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WORD  NAME:  Replay  Type/Speed 


WORD  ID: 

R1 -009-02 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 

0  msb  Bits  0-3:  A  series  of  binary  values  representing  the  type  of  replay. 

Bit  No.  0123 

0000  =  Begin  Replay  @  Time  and  Speed' 

0001  =  Play  Eive  (ignore  bits  4-7) 

0010  =  Continue  Replay  @  Speed^ 

001 1-1111=  Reserved 

Bits  4-7 :  A  series  of  binary  values  indicating  replay  speed. 

Bit  No.  4567 

0000  =  Pause  (Speed  Zero) 

0001  =  Normal  Speed  (real-time) 

0010  -  1 1 1 1  per  R/R  Specification 

15  Isb  Bit  8-15  Binary  0 

Note  1:  Begin  Replay  @  Time  and  Speed  command  option  is  only  valid  when  replay  is 

currently  stopped  (see  STOP  receive  command).  The  Replay  message  time  words 
(data  words  3-6)  are  used  to  locate  the  desired  replay  point.  If  the  time  specified  in 
these  replay  time  words  is  not  found  in  the  recorded  data,  the  R/R  will  set  the  East 
Receive  Command  Error  bit  in  the  Status  transmit  message. 

Note  2:  Continue  Replay  @  Speed  command  option  is  used  following  a  Queue  command  to 
initiate  replay  at  the  queued  replay  point.  It  is  also  used  to  change  replay  speeds  or 
pause  and  resume  replay  at  the  current  replay  point.  The  Replay  message  time  words 
are  unused  and  zero-filled. 


WORD  NAME  Replay  Time  Word  1 


WORD  ID: 

R1 -009-03 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 
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BIT  NO.  DESCRIPTION 


0 

1 

2 

msb 

Hex  Digit  #1  =  Tens  of  seconds,  binary  0  to  5 

3 

Isb 

4 

5 

6 

msb 

Hex  Digit  #2  =  Units  of  seconds,  binary  0  to  9 

7 

Isb 

8 

9 

10 

msb 

Hex  Digit  #3  =  Hundreds  of  milliseconds,  binary  0  to  9 

11 

Isb 

12 

13 

14 

msb 

Hex  Digit  #4  =  Tens  of  milliseconds,  binary  0  to  9 

15 

Isb 

WORD  NAME  Replay  Time  Word  2 


WORD  ID: 

R1 -009-04 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0 

1 

2 

msb 

Hex  Digit  #1  =  Tens  of  hours,  binary  0  to  2^ 

3 

Isb 

4 

5 

6 

msb 

Hex  Digit  #2  =  Units  of  hours,  binary  0  to  9^ 

7 

Isb 

8 

9 

10 

msb 

Hex  Digit  #3  =  Tens  of  minutes,  binary  0  to  5 

11 

Isb 

12 

13 

14 

msb 

Hex  Digit  #4  =  Units  of  minutes,  binary  0  to  9 
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15  isb  - 

Note  1.  Hex  digit  #1  and  hex  digit  #2  (tens  of  hours  and  units  of  hours)  must  together  be  a 
deeimal  number  from  00  to  23 


WORD  NAME  Replay  Time  Word  3 


WORD  ID: 

R1 -009-05 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodie 

SIGNAE  TYPE 

Diserete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0 

msb 

1 

2 

3 

Isb 

4 

msb 

5 

6 

7 

Isb 

8 

msb 

9 

10 

11 

Isb 

12 

msb 

13 

14 

15 

Isb 

Hex  Digit  #I  =  Tens  of  months,  binary  0  to  I^ 


Hex  Digit  #2  =  Units  of  months,  binary  0  to  9' 


Hex  Digit  #3  =  Tens  of  days,  binary  0  to  3^’  ^ 


Hex  Digit  #4  =  Units  of  days,  binary  0  to  9^’  ^ 


Note  I.  Hex  digit  #I  and  hex  digit  #2  (tens  of  months  and  units  of  months)  must  together  be  a 
deeimal  number  from  01  to  12 

Note  2.  Hex  digit  #3  and  hex  digit  #4  (tens  of  days  and  units  of  days)  must  together  be  a 
deeimal  number  from  01  to  31 

Note  3.  Hex  digit  #3  and  hex  digit  #4  (tens  of  days  and  units  of  days)  must  together  be  a  valid 
number  of  days  in  the  month  identified  by  hex  digit  #1  and  hex  digit  #2.  Eor 
example,  month  06  may  only  have  a  maximum  of  30  days. 


WORD  NAME  Replay  Time  Word  4 

WORD  ID:  Rl-009-06  RANGE:  N/A 
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SOURCE: 

BC  ACCURACY:  N/A 

DESTINATION: 

R/R  Isb:  N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0 

msb 

1 

Hex  Digit  #I  =  Thousands  of  years,  binary  0  to  2 

2 

3 

Isb 

4 

msb 

5 

Hex  Digit  #2  =  Hundreds  of  years,  binary  0  to  9 

6 

7 

Isb 

8 

msb 

9 

Hex  Digit  #3  =  Tens  of  years,  binary  0  to  9 

10 

II 

Isb 

12 

msb 

13 

Hex  Digit  #4  =  Units  of  years,  binary  0  to  9 

14 

15 

Isb 

A.I.k. 

Reset  Command 

The  Reset  command  is  used  to  start  a  reset  of  the  R/R.  Upon  receipt  of  a  valid  Reset 
command,  the  R/R  negates  the  ready  discrete  output  and  all  subsequent  RT  messages  addressed 
to  the  R/R  will  be  ignored  until  the  ready  discrete  output  is  reasserted. 


MESSAGE  NAME:  Reset 


MESSAGE  ID: 

SOURCE: 

DESTINATION: 


RI-0I3  TRANSEER  TYPE:  BC-RT 

BC  WORD  COUNT:  32 

R/R 


WORD  NAME 
Command  Word 
Reset  Command  ID 
Zero 

Status  Word 


WORD  NO. _ DESCRIPTION 

CW  Subaddress  00001  binary 

01  ID  of  Reset  command  =  OxOOOD 

02-32  Zero-filled 

SW  MIE-STD-1553  Status  Word 


WORD  NAME:  Reset  Command  ID 


WORD  ID:  R1-0I3-0I  RANGE:  N/A 
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SOURCE:  BC  ACCURACY: 

DESTINATION:  R/R  Isb: 

XMIT  RATE  Aperiodic 

SIGNAE  TYPE  Discrete 

UNITS  N/A 


BIT  NO. 

DESCRIPTION 

0 

msb 

1 

Hex  Digit  #1  =  0 

2 

3 

Isb 

4 

msb 

5 

Hex  Digit  #2  =  0 

6 

7 

Isb 

8 

msb 

9 

Hex  Digit  #3  =  0 

10 

11 

Isb 

12 

msb 

13 

Hex  Digit  #4  =  D 

14 

15 

Isb 

N/A 

N/A 


A.I.l.  Resume  Command 

The  Resume  command  is  used  to  instruct  the  R/R  to  resume  recording  of  one  or  more 
channels,  either  by  channel  type  or  specific  channel  IDs. 


MESSAGE  NAME:  Resume 


MESSAGE  ID: 

Rl-014 

TRANSEER  TYPE: 

BC-RT 

SOURCE: 

BC  WORD  COUNT:  32 

DESTINATION: 

R/R 

WORD  NAME 

WORD  NO. 

DESCRIPTION 

Command  Word 

CW 

Subaddress  00001  binary 

Resume  Command  ID 

01 

ID  of  Resume  command  =  OxOOOE 

Resume  Condition 

02 

Channel  group  or  individual  channels 

Resume  Channel  ID 

03-16 

Individual  Channel  ID  or  zero 

Zero 

17-32 

Zero-filled 

Status  Word 

SW 

MIE-STD-1553  Status  Word 

WORD  NAME:  Resume  Command  ID 


A-21 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  6,  July  2017 


WORD  ID: 

RI-0I4-0I 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0 

msb 

I 

Hex  Digit  #1  =  0 

2 

3 

Isb 

4 

msb 

5 

Hex  Digit  #2  =  0 

6 

7 

Isb 

8 

msb 

9 

Hex  Digit  #3  =  0 

10 

II 

Isb 

12 

msb 

13 

Hex  Digit  #4  =  E 

14 

15 

Isb 

WORD  NAME:  Resume  Condition 


WORD  ID: 

RI-0I4-02 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

Binary  0 

Bits  1-3  are  three-bit  codes  that  specify  the  type  of  resume 

Bit  No. 

123 

000  =  Individual  Channel(s) 

001  =  All  Channels 

Remaining  bits  reserved 
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4 

Binary  0 

5 

Binary  0 

7 

Binary  0 

8 

Binary  0 

9 

Binary  0 

10 

Binary  0 

11 

Binary  0 

12 

Binary  0 

13 

Binary  0 

14 

Binary  0 

15  Isb 

Binary  0 

WORD  NAME: 

Resume  Channel  ID 

WORD  ID: 
SOURCE: 
DESTINATION: 
XMIT  RATE 
SIGNAE  TYPE 
UNITS 

Rl-014-03toRl-014-16 

BC 

R/R 

Aperiodic 

Discrete 

N/A 

RANGE:  N/A 

ACCURACY:  N/A 

Isb:  N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

1 

2 

Bit  0  -  15  is  the  unsigned  integer  Channel  ID  number  of  a 
channel  to  be  resumed  when  Bits  1-3  of  data  word  2  equal  1 10, 
otherwise  these  data  words  3  to  16  are  unused  and  zero-filled. 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


A.l.m.  Sanitize  Command 

The  Sanitize  command  performs  a  Chapter  10  sanitization  procedure  on  internal  memory 
or  RMM  installed  in  the  R/R.  While  in  the  Sanitize  state,  the  percent  complete  is  output  via  the 
STATUS  transmit  command.  When  the  Sanitize  procedure  completes,  the  state  of  the  R/R  as 
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returned  by  the  STATUS  transmit  command  indicates  either  “pass”  (state  =  SANITIZE  PASS) 
or  “fail”  (state  =  SANITIZE  EAIE). 


MESSAGE  NAME:  Sanitize 


MESSAGE  ID: 

Rl-003  TRANSEER  TYPE:  BC-RT 

SOURCE: 

BCWORD  COUNT: 

32 

DESTINATION: 

R/R 

WORD  NAME 

WORD  NO. 

DESCRIPTION 

Command  Word 

CW 

Subaddress  00001  binary 

Sanitize  Command  ID  01 

ID  of  Sanitize  command  =  0x0003 

Zero 

2-32 

Zero-filled 

Status  Word 

SW 

MIE-STD-1553  Status  Word 

WORD  NAME: 

Sanitize  Command  ID 

WORD  ID: 

R 1-003-01 

RANGE:  N/A 

SOURCE: 

BC 

ACCURACY:  N/A 

DESTINATION: 

R/R 

Isb:  N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

1 

Hex  Digit  #1  =  0 

2 

3  Isb 

4  msb 

5 

Hex  Digit  #2  =  0 

6 

7  Isb 

8  msb 

9 

Hex  Digit  #3  =  0 

10 

11  Isb 

12  msb 

13 

Hex  Digit  #4  =  3 

14 

15  Isb 
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A.l.n.  Stop  Command 

The  Stop  command  is  used  to  stop  recording,  replay,  or  both. 


MESSAGE  NAME:  Stop 


MESSAGE  ID: 

RI-0I6  TRANSEER 

SOURCE: 

BC  WORD  COUNT: 

DESTINATION: 

R/R 

WORD  NAME 

WORD  NO. 

Command  Word 

CW 

Stop  Command  ID  01 

Stop  Mode 

02 

Zero 

03-32 

Status  Word 

sw 

WORD  NAME: 

Stop  Command  ID 

WORD  ID: 

R1-016-0I 

SOURCE: 

BC 

DESTINATION: 

R/R 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

TYPE:  BC-RT 
32 


DESCRIPTION 
Subaddress  00001  binary 
ID  of  Stop  command  =  0x0010 
One  of  three  possible  stop  modes 
Zero-filled 

MIE-STD-1553  Status  Word 


RANGE: 

N/A 

ACCURACY: 

N/A 

Isb: 

N/A 

BIT  NO. 


DESCRIPTION 


0 

msb 

1 

Hex  Digit  #1  =  0 

2 

3 

Isb 

4 

msb 

5 

Hex  Digit  #2  =  0 

6 

7 

Isb 

8 

msb 

9 

Hex  Digit  #3=1 

10 

11 

Isb 

12 

msb 

13 

Hex  Digit  #4  =  0 

14 

15 

Isb 
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WORD  NAME 

Stop  Mode 

WORD  ID: 

Rl-016-02 

RANGE:  N/A 

SOURCE: 

BC 

ACCURACY:  N/A 

DESTINATION: 

R/R 

Isb:  N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

Two-bit  binary  code  with  bit  1 

1 

Two-bit  binary  code  with  bit  0 

Bit-0  Bit-1 

Description 

0  0 

Stop  Recording  and  Close  Eile 

0  1 

Stop  Replay^ 

1  0 

Stop  Recording,  Close  Eile,  and  Stop  Replay 

1  1 

Invalid  Command  (reserved) 

2 

Binary  0 

3 

Binary  0 

4 

Binary  0 

5 

Binary  0 

6 

Binary  0 

7 

Binary  0 

8 

Binary  0 

9 

Binary  0 

10 

Binary  0 

11 

Binary  0 

12 

Binary  0 

13 

Binary  0 

14 

Binary  0 

15  Isb 

Binary  0 

A. 1.0.  Time  Command 

The  Time  command  is  used  in  conjunction  with  the  SYNC  command  to  set  the  internal 
Time  Channel  time  in  the  R/R  when  the  Time  Channel  health  status  “synchronization  failure”  bit 
equals  “1”. 


MESSAGE  NAME:  Time 


MESSAGE  ID: 

SOURCE: 

DESTINATION: 


Rl-017  TRANSEER  TYPE:  BC-RT 

BC  WORD  COUNT:  32 

R/R 
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WORD  NAME 

WORD  NO. 

DESCRIPTION 

Command  Word 

CW 

Subaddress  00001  binary 

Time  Command  ID 

01 

ID  of  Time  command  =  0x001 1 

Set  Time  Valid 

02 

Indicates  when  words  4-7  have  valid  time 

Time  of  Validity 

03 

Indicates  sync  time  when  time  was  valid 

Set  Time  Word  1 

04 

Seconds  and  Milliseconds  word 

Set  Time  Word  2 

05 

Hours  and  Minutes  word 

Set  Time  Word  3 

06 

Month  and  Day  word 

Set  Time  Word  4 

07 

Year  word 

Zero 

8-32 

Zero-filled 

Status  Word 

sw 

MIE-STD-1553  Status  Word 

WORD  NAME: 

Time  Command  ID 

WORD  ID: 

Rl-017-01 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

1 

Hex  Digit  #1=0 

2 

3  Isb 

4  msb 

5 

Hex  Digit  #2  =  0 

6 

7  Isb 

8  msb 

9 

Hex  Digit  #3  =  1 

10 

11  Isb 

12  msb 

13 

Hex  Digit  #4=1 

14 

15  Isb 

WORD  NAME 

Set  Time  Valid 

WORD  ID: 

Rl-017-02 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 
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DESTINATION:  R/R 

XMIT  RATE  Aperiodic 

SIGNAE  TYPE  Discrete 

UNITS  N/A 


Isb: 


N/A 


BIT  NO. 


DESCRIPTION 


0  msb 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15  Isb 


Time  Valid  bit:  1  =  time  words  valid,  0  =  time  words  not  valid 

Binary  0 

Binary  0 

Binary  0 

Binary  0 

Binary  0 

Binary  0 

Binary  0 

Binary  0 

Binary  0 

Binary  0 

Binary  0 

Binary  0 

Binary  0 

Binary  0 

Binary  0 


WORD  NAME 

WORD  ID: 
SOURCE: 
DESTINATION: 
XMIT  RATE 
SIGNAE  TYPE 
UNITS 


Time  of  Validity 

Rl-017-03 

BC 

R/R 

Aperiodic 

Discrete 

N/A 


RANGE: 

ACCURACY: 

Isb: 


N/A 

N/A 

50  microseconds 


BIT  NO. 


DESCRIPTION 


0  msb 
1 
2 

3 

4 

5 

6 

7 

8 
9 


Bits  0-15:  An  unsigned  binary  integer  representing  the  time  at  which 
the  Set  Time  is  valid,  based  on  the  BC  clock  synchronization  time. 
The  Isb  is  50  microseconds. 
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10 

11 

12 

13 

14 

15  Isb 


WORD  NAME  Set  Time  Word  1 


WORD  ID: 

Rl-017-04 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0 

1 

2 

msb 

Hex  Digit  #1  =  Tens  of  seconds,  binary  0  to  5 

3 

Isb 

4 

5 

6 

msb 

Hex  Digit  #2  =  Units  of  seconds,  binary  0  to  9 

7 

Isb 

8 

9 

10 

msb 

Hex  Digit  #3  =  Hundreds  of  milliseconds,  binary  0  to  9 

11 

Isb 

12 

13 

14 

msb 

Hex  Digit  #4  =  Tens  of  milliseconds,  binary  0  to  9 

15 

Isb 

WORD  NAME  Set  Time  Word  2 


WORD  ID: 

Rl-017-05 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 
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BIT  NO. 

msb 


DESCRIPTION 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 


Isb 

msb 


Isb 

msb 


Isb 

msb 


Isb 


Hex  Digit  #1  =  Tens  of  hours,  binary  0  to  2^ 


Hex  Digit  #2  =  Units  of  hours,  binary  0  to  9^ 


Hex  Digit  #3  =  Tens  of  minutes,  binary  0  to  5 


Hex  Digit  #4  =  Units  of  minutes,  binary  0  to  9 


Note  1.  Hex  digit  #1  and  hex  digit  #2  (tens  of  hours  and  units  of  hours)  must  together  be  a 
decimal  number  from  00  to  23 


WORD  NAME  Set  Time  Word  3 


WORD  ID: 

Rl-017-06 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0 

msb 

1 

2 

3 

Isb 

4 

msb 

5 

6 

7 

Isb 

8 

msb 

9 

10 

11 

Isb 

12 

msb 

Hex  Digit  #1  =  Tens  of  months,  binary  0  to  1^ 


Hex  Digit  #2  =  Units  of  months,  binary  0  to  9' 


Hex  Digit  #3  =  Tens  of  days,  binary  0  to  3^’  ^ 
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13  Hex  Digit  #4  =  Units  of  days,  binary  0  to  9^’  ^ 

14 

15  isb  - 

Note  1.  Hex  digit  #1  and  hex  digit  #2  (tens  of  months  and  units  of  months)  must  together  be  a 
decimal  number  from  01  to  12 

Note  2.  Hex  digit  #3  and  hex  digit  #4  (tens  of  days  and  units  of  days)  must  together  be  a 
decimal  number  from  01  to  31 

Note  3.  Hex  digit  #3  and  hex  digit  #4  (tens  of  days  and  units  of  days)  must  together  be  a  valid 
number  of  days  in  the  month  identified  by  hex  digit  #1  and  hex  digit  #2.  For 
example,  month  06  may  only  have  a  maximum  of  30  days. 


WORD  NAME  Set  Time  Word  4 


WORD  ID: 

R 1-0 17-07 

RANGE: 

N/A 

SOURCE: 

BC 

ACCURACY: 

N/A 

DESTINATION: 

R/R 

Isb: 

N/A 

XMIT  RATE 

Aperiodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0 

msb 

1 

2 

3 

Isb 

Hex  Digit  #1  =  Thousands  of  years,  binary  0  to  2 

4 

msb 

5 

6 

7 

Isb 

Hex  Digit  #2  =  Hundreds  of  years,  binary  0  to  9 

8 

msb 

9 

10 

11 

Isb 

Hex  Digit  #3  =  Tens  of  years,  binary  0  to  9 

12 

msb 

13 

14 

15 

Isb 

Hex  Digit  #4  =  Units  of  years,  binary  0  to  9 

A.l.p. 

Svnc  Command 

The  Sync  command  is  used  to  send  the  current  value  of  the  BC  clock  synchronization 
time  to  the  R/R. 
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MESSAGE  NAME:  Sync 

MESSAGE  ID:  R2  TRANSEER  TYPE:  BC-RT 

SOURCE:  BC  WORD  COUNT:  1 

DESTINATION:  R/R 

WORD  NAME _ WORD  NO 

Command  Word  CW 

Synchronization  Time  01 

Status  Word  SW 

WORD  NAME:  Synchronization  Time 

WORD  ID:  R2-0I 

SOURCE:  BC 

DESTINATION:  R/R 

XMIT  RATE  Aperiodic 

SIGNAE  TYPE  Discrete 

UNITS  N/A 

BIT  NO.  DESCRIPTION 

0  msb  - 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  isb  - 

Note:  50  microsecond  count  used  to  synchronize  the  internal  R/R  clock  to  the  BC  clock. 

When  a  TIME  command  is  received  by  the  R/R,  the  most  recent  SYNC  command 
clock  synchronization  word  is  used  to  calculate  the  correct  time  to  load  into  the  R/R 
clock  based  on  the  time  of  validity  parameter  contained  in  the  TIME  command. 


RANGE:  N/A 

ACCURACY:  N/A 

Isb:  50  microseconds 


DESCRIPTION 
Subaddress  00010  binary 
BC  Clock  Synchronization  Time 
MIE-STD-1553  Status  Word 
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A.2.  Transmit  Messages 


Table  A-2  provides  a  description  of  the  MIL-STD-1553  transmit  commands  defined  in 
the  following  sections. 


Table  A-2.  Military  Standard  1553  Transmit  (Remote  Terminal  to  Bus 

Controller)  Command  Set 

Command 

Subaddress 

Description 

EVENTS 

2 

Returns  the  number  of  occurrences  of  defined  events 

HEAETH 

3 

Returns  detailed  R/R  health  information 

INEO 

4 

Returns  detailed  information  about  a  specific  file  or  event  in 
response  to  a  received  INEO  BC  to  RT  message  (see  Table  A-1) 

STATUS 

5 

Returns  the  current  system  status  and  statistics 

A. 2. a.  Transmit  Message  Length 

All  response  (transmit)  messages  have  32  data  words.  All  unused  data  words  are  zero- 
filled.  If  the  BC  requests  less  than  32  words  in  the  RT  to  BC  command  word,  only  a  valid  status 
word  and  the  requested  number  of  data  words  will  be  transmitted. 

A.2.b.  Events  Command 

Each  time  the  BC  sends  an  Event  command  (R 1-005  above),  the  R/R  will  increment  the 
internal  “occurrence”  counter  for  the  specified  event.  This  Event  command  causes  the  R/R  to 
transmit  the  number  of  occurrences  of  events  1  to  31.  Undefined  event  occurrence  counts  are  0. 


MESSAGE  NAME:  Events 


MESSAGE  ID:  T3 

TRANSEER  TYPE: 

RT-BC 

SOURCE:  R/R 

DESTINATION:  BC 

WORD  COUNT: 

32 

WORD  NAME 

WORD  NO. 

DESCRIPTION 

Command  Word 

CW 

Subaddress  0001 1  binary 

Status  Word 

SW 

MIE-STD-1553  Status  Word 

Event  I  Occurrences 

01 

Number  of  times  Event  1  occurred 

Event  2  Occurrences 

02 

Number  of  times  Event  2  occurred 

Event  3  Occurrences 

03 

Number  of  times  Event  3  occurred 

Event  4  Occurrences 

04 

Number  of  times  Event  4  occurred 

Event  5  Occurrences 

05 

Number  of  times  Event  5  occurred 

Event  6  Occurrences 

06 

Number  of  times  Event  6  occurred 

Event  7  Occurrences 

07 

Number  of  times  Event  7  occurred 

Event  8  Occurrences 

08 

Number  of  times  Event  8  occurred 

Event  9  Occurrences 

09 

Number  of  times  Event  9  occurred 

Event  10  Occurrences 

10 

Number  of  times  Event  10  occurred 

Event  II  Occurrences 

II 

Number  of  times  Event  1 1  occurred 

Event  12  Occurrences 

12 

Number  of  times  Event  12  occurred 
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Event  13  Occurrences  13 

Event  14  Occurrences  14 

Event  15  Occurrences  15 

Event  16  Occurrences  16 

Event  17  Occurrences  17 

Event  18  Occurrences  18 

Event  19  Occurrences  19 

Event  20  Occurrences  20 

Event  21  Occurrences  21 

Event  22  Occurrences  22 

Event  23  Occurrences  23 

Event  24  Occurrences  24 

Event  25  Occurrences  25 

Event  26  Occurrences  26 

Event  27  Occurrences  27 

Event  28  Occurrences  28 

Event  29  Occurrences  29 

Event  30  Occurrences  30 

Event  3 1  Occurrences  3 1 

Zero  32 


Number  of  times  Event  13  occurred 
Number  of  times  Event  14  occurred 
Number  of  times  Event  15  occurred 
Number  of  times  Event  16  occurred 
Number  of  times  Event  17  occurred 
Number  of  times  Event  18  occurred 
Number  of  times  Event  19  occurred 
Number  of  times  Event  20  occurred 
Number  of  times  Event  21  occurred 
Number  of  times  Event  22  occurred 
Number  of  times  Event  23  occurred 
Number  of  times  Event  24  occurred 
Number  of  times  Event  25  occurred 
Number  of  times  Event  26  occurred 
Number  of  times  Event  27  occurred 
Number  of  times  Event  28  occurred 
Number  of  times  Event  29  occurred 
Number  of  times  Event  30  occurred 
Number  of  times  Event  3 1  occurred 
Zero-filled 


WORD  NAME:  Event  N  Occurrences 


WORD  ID: 
SOURCE: 
DESTINATION: 
XMIT  RATE 
SIGNAE  TYPE 
UNITS 


T3-01  toT3-31 

R/R 

BC 

Periodic 

Discrete 

N/A 


RANGE:  0  -  65535 

ACCURACY:  N/A 

Isb:  N/A 


BIT  NO. 


DESCRIPTION 


0  msb 
1 
2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 


Bit  0  -  15  is  the  unsigned  integer  number  of  times  that  the  corresponding 
Event  occurred  or  zero  if  the  corresponding  event  is  undefined. 
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13 

14 

15  Isb 


A.2.C.  Health  Command 

The  Health  command  returns  status  bits  that  indicate  warning  or  error  conditions  within 
the  R/R.  Any  non-zero  health  bit  is  either  a  warning  condition  or  an  error  condition.  Detailed 
health  bit  descriptions  are  provided  in  Table  6-2. 


MESSAGE  NAME:  Health 


MESSAGE  ID:  T4 
SOURCE:  R/R 

DESTINATION:  BC 


TRANSEER  TYPE:  RT  -  BC 
WORD  COUNT:  32 


WORD  NAME 

Command  Word 


Status  Word 
Recorder  Health 
Channel  Health 


WORD  NO. _ DESCRIPTION 

CW  Subaddress  00100  binary 

Subaddresses  00111  -  10000  binary 
are  used  to  extend  Health  command 
channel  health  word  count. 

SW  MIE-STD-1553  Status  Word 

01  Recorder  and  RMM  status  bits 

02-32  Individual  channel  status  bits 


Note:  Channel  health  status  bits  are  lAW  the  .HEAETH  command  defined  in  Subsection 

6.2.3.3. 


Time  Channel  Health  02 


Time  channel  status  bits 


WORD  NAME:  Recorder  Health 


WORD  ID: 

T4-01 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

lAW  .HEAETH  use  of  status  bits  table  (ch6) 

1 

lAW  .HEAETH  use  of  status  bits  table 

2 

lAW  .HEAETH  use  of  status  bits  table 

3 

lAW  .HEAETH  use  of  status  bits  table 
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4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
Drive  Lull 
Drive  EO  Eailure 
No  Drive 
Unused  (zero) 

Operation  Eailure 
Setup  Eailure 
Bit  Eailure 


WORD  NAME:  Time  Channel  Health 


WORD  ID: 

T4-02 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAL  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0  msb 
1 
2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
lAW  .HEALTH  use  of  status  bits  table 
Synchronization  Eailure 
Bad  External  Signal 
No  External  Signal 
Setup  Eailure 
Bit  Eailure 


WORD  NAME:  Channel  (n)  Health 

WORD  ID:  T4-03  -  T4-32  RANGE:  N/A 
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SOURCE:  R/R  ACCURACY:  N/A 

DESTINATION:  BC  Isb:  N/A 

XMIT  RATE  Periodic 

SIGNAE  TYPE  Discrete 

UNITS  N/A 

BIT  NO.  DESCRIPTION 


0  msb 
1 
2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15  Isb 


lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
lAW  .HEAETH  use 
Bit  Eailure 


of  status  bits  table 
of  status  bits  table 
of  status  bits  table 
of  status  bits  table 
of  status  bits  table 
of  status  bits  table 
of  status  bits  table 
of  status  bits  table 
of  status  bits  table 
of  status  bits  table 
of  status  bits  table 
of  status  bits  table 
of  status  bits  table 
of  status  bits  table 
of  status  bits  table 


A.2.d.  Info  (transmit)  Command 

The  Info  transmit  command  retrieves  internal  memory  or  RMM  data  file  start  and  end 
time  or  an  event  occurrence  time  as  requested  by  the  most  recent  Info  receive  (R 1-007) 
command.  Validity  bits  in  data  words  1  and  10  indicate  when  the  specific  file  or  event 
information  is  valid. 


MESSAGE  NAME:  Info  (transmit) 


MESSAGE  ID: 

T5 

TRANSEER  TYPE: 

RT-BC 

SOURCE: 

R/R 

WORD  COUNT: 

32 

DESTINATION: 

BC 

WORD  NAME 

WORD  NO. 

DESCRIPTION 

Command  Word 

CW 

Subaddress  00101  binary 

Status  Word 

SW 

MIE-STD-1553  Status  Word 

Eile  Number 

01 

Info  requested  for  this  file 

Eile  Start  Time  Word  1 

02 

Pile  start  time  seconds  &  milliseconds 

Eile  Start  Time  Word  2 

03 

Pile  start  time  hours  &  minutes 

Eile  Start  Time  Word  3 

04 

Pile  start  time  month  &  days 
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File  Start  Time  Word  4 

05 

File  start  time  year 

File  End  Time  Word  1 

06 

File  end  time  seconds  &  milliseconds 

File  End  Time  Word  2 

07 

File  end  time  hours  &  minutes 

File  End  Time  Word  3 

08 

File  end  time  month  &  days 

File  End  Time  Word  4 

09 

File  end  time  year 

Event  Number 

10 

Info  requested  for  this  event 

Event  Occurrence 

11 

Info  requested  for  this  occurrence 

Event  Time  Word  1 

12 

Event  time  seconds  &  milliseconds 

Event  Time  Word  2 

13 

Event  time  hours  &  minutes 

Event  Time  Word  3 

14 

Event  time  month  &  days 

Event  Time  Word  4 

15 

Event  time  year 

Zero 

16-32 

Zero-filled 

WORD  NAME: 

File  Number 

WORD  ID: 

T5-01 

RANGE: 

see  below 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 

0  msb  Bit  0:  File  Info  Validity;  Valid  =  1,  Invalid  =  0 

1  Bit  1  -  15  is  the  unsigned  integer  file  number  of  the  requested  file  from 

2  1  to  the  number  of  files  in  Status  message  data  word  5  (T6-005) 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 

Note:  File  Info  Validity  applies  to  the  file  number  in  this  data  word  and  the  start  and  end 

times  in  the  next  eight  data  words. 

WORD  NAME  File  Start,  File  End,  or  Event  Time  Word  1 
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WORD  ID: 

T5-02,  T5-06,orT5-I2 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0 

1 

2 

msb 

Hex  Digit  #1  =  Tens  of  seconds,  binary  0  to  5 

3 

Isb 

4 

5 

6 

msb 

Hex  Digit  #2  =  Units  of  seconds,  binary  0  to  9 

7 

Isb 

8 

9 

10 

msb 

Hex  Digit  #3  =  Hundreds  of  milliseconds,  binary  0  to  9 

11 

Isb 

12 

13 

14 

msb 

Hex  Digit  #4  =  Tens  of  milliseconds,  binary  0  to  9 

15 

Isb 

WORD  NAME 

Eile  Start,  Eile  End,  or  Event  Time  Word  2 

WORD  ID: 

T5-03,  T5-07,orT5-13 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

1 

Hex  Digit  #1  =  Tens  of  hours,  binary  0  to  2^ 

2 

3  Isb 

4  msb 

5 

A 

Hex  Digit  #2  =  Units  of  hours,  binary  0  to  9^ 

o 

7  Isb 
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8  msb  - 

9  Hex  Digit  #3  =  Tens  of  minutes,  binary  0  to  5 

10 

11  isb  - 

12  msb  - 

13  Hex  Digit  #4  =  Units  of  minutes,  binary  0  to  9 

14 

15  isb  - 

Note  1.  Hex  digit  #1  and  hex  digit  #2  (tens  of  hours  and  units  of  hours)  must  together  be  a 
decimal  number  from  00  to  23. 


WORD  NAME  File  Start,  File  End,  or  Event  Time  Word  3 


WORD  ID: 

T5-04,  T5-08,orT5-14 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

1 

Hex  Digit  #1  =  Tens  of  months,  binary  0  to  1^ 

2 

3  Isb  - 

4  msb  - 

5  Hex  Digit  #2  =  Units  of  months,  binary  0  to  9' 

6 

7  Isb  - 

8  msb  - 

9  Hex  Digit  #3  =  Tens  of  days,  binary  0  to  3^’  ^ 


10 

11 

Isb  - 

12 

msb  - 

13 

14 

Hex  Digit  #4  =  Units  of  days,  binary  0  to  9^’  ^ 

15 

Isb  - 

Note  1. 

Hex  digit  #1  and  hex  digit  #2  (tens  of  months  and  units  of  months) 
decimal  number  from  01  to  12. 

must  together  be  a 

Note  2. 

Hex  digit  #3  and  hex  digit  #4  (tens  of  days  and  units  of  days)  must 
decimal  number  from  01  to  31. 

together  be  a 
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Note  3.  Hex  digit  #3  and  hex  digit  #4  (tens  of  days  and  units  of  days)  must  together  be  a  valid 
number  of  days  in  the  month  identified  by  hex  digit  #1  and  hex  digit  #2.  For 
example,  month  06  may  only  have  a  maximum  of  30  days. 


WORD  NAME  File  Start,  File  End,  or  Event  Time  Word  4 


WORD  ID: 

T5-05,  T5-09,orT5-15 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0 

1 

2 

msb 

Hex  Digit  #1  =  Thousands  of  years,  binary  0  to  2 

3 

Isb 

4 

5 

6 

msb 

Hex  Digit  #2  =  Hundreds  of  years,  binary  0  to  9 

7 

Isb 

8 

9 

10 

msb 

Hex  Digit  #3  =  Tens  of  years,  binary  0  to  9 

11 

Isb 

12 

13 

14 

msb 

Hex  Digit  #4  =  Units  of  years,  binary  0  to  9 

15 

Isb 

WORD  NAME:  Event  Number 


WORD  ID: 

T5-10 

RANGE: 

see  below 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0  msb  Bit  0:  Event  Info  Validity;  Valid  =  1,  Invalid  =  0 

1  Bit  1  -  15  is  the  unsigned  integer  event  number  of  the  requested  event 


A-41 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  6,  July  2017 


2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


from  1  to  the  number  of  defined  events  in  Status  message  data  word  14 
(T6-014) 


Note:  Event  Info  Validity  applies  to  the  event  number  in  this  data  word,  the  event 

occurrence  number  in  data  word  11,  and  the  event  time  in  data  words  12,  13,  14,  and 
15. 


WORD  NAME:  Event  Occurrence 


WORD  ID: 

T5-11 

RANGE: 

1  -  65535 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0  msb 
1 
2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


Bit  0  -  15  is  the  unsigned  integer  event  occurrence  number  of  the 
requested  BC  event 
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A.2.e.  Status  Command 

The  Status  command  retrieves  R/R  status  and  configuration  information.  A  validity  bit  in 
data  word  1  indicates  when  the  status  and  configuration  information  is  valid. 


MESSAGE  NAME:  Status 


MESSAGE  ID:  T6 

TRANSPER  TYPE: 

RT-BC 

SOURCE:  R/R 

WORD  COUNT: 

32 

DESTINATION:  BC 

WORD  NAME 

WORD  NO. 

DESCRIPTION 

Command  Word 

CW 

Subaddress  001 10  binary 

Status  Word 

sw 

MIE-STD-I553  Status  Word 

State/Speed/Video/Error 

01 

Multiple  system  status  fields 

Command  Percent  Complete 

02 

Record/BIT/Erase/Sanitize  %  complete 

Internal  Memory/RMM  Size 

03 

Internal  Memory/RMM  capacity  in 

gigabytes 

Memory  Percent  Available 

04 

Amount  (%)  of  unused  memory 

Number  of  Piles 

05 

Number  of  used  file  table  entries 

System  Time  Word  1 

06 

System  time  seconds  &  milliseconds 

System  Time  Word  2 

07 

System  time  hours  &  minutes 

System  Time  Word  3 

08 

System  time  month  &  days 

System  Time  Word  4 

09 

System  time  year 

Replay  Time  Word  1 

10 

Current  replay  time  seconds  &  milliseconds 

Replay  Time  Word  2 

11 

Current  replay  hours  &  minutes 

Replay  Time  Word  3 

12 

Current  replay  month  &  days 

Replay  Time  Word  4 

13 

Current  replay  year 

Number  of  Defined  Events 

14 

Number  of  BC  events  in  TMATS  file 

Pirmware  Version 

15 

Pirmware  version  numbers 

TMATS  Pile  Revision 

16 

TMATS  Setup  Pile  revision  number 

Zero 

17-32 

Zero-filled 

WORD  NAME  State/Speed  /Error 


WORD  ID: 

T6-0I 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

Bit  0  -  3  =  one  of  the  following  state  codes 
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Bit 


0123 

0000  =  FAIL 

0001  =  IDLE 

0010  =  BIT 

0011  =  ERASE 

0100  =  SANITIZE 

0101  =  RECORD 

0110  =  PEAY 

0111  =  RECORD  &  PEAY 

1000  =  QUEUE  (EIND) 

1001  =  BUSY 

1010  =  COMMAND  ERROR 

101 1  =  SANITIZE  ERROR 
1100  =  SANITIZE  PASS 
1101-1111  =  Reserved 


Bit  4  -  7  =  binary  value  representing  current  replay  speed 
Bit  4567 

0000  =  Pause  (Speed  Zero) 

0001  =  Normal  Speed  (Real-Time) 

0010  -  nil  =  User  Defined 


Bits  8-10:  Reserved 

Bit  1 1 :  East  Receive  Command  Error 

0  =  East  BC  to  RT  command  was  valid  and  accepted 

1  =  East  BC  to  RT  command  was  illegal/invalid  and  rejected 

Bit  12:  Status  message  validity 
0  =  All  message  words  are  invalid 
1  =  All  message  words  are  valid 

Bits  13-14:  Queue  command  status 
Bit  13  14 

0  0  =  No  queue  command  status 

0  1=  Queue  command  passed 
10=  Queue  command  failed 
11=  Queue  command  in  progress 

15  Isb  Play  Eive  Mode  status^ 

0  =  Not  in  Play  Eive  mode 
1  =  In  Play  Eive  mode 

Note  1 .  Play  Eive  Mode  status  is  cleared  by  the  Stop  Replay  command. 
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WORD  NAME:  Command  Percent  Complete 


WORD  ID: 

T6-02 

RANGE: 

0-100 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0  msb 
1 
2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


Bit  0  -  15  is  the  unsigned  integer  percent  complete  for  the  Record, 
Record  &  Play,  BIT,  Erase,  or  Sanitize  command  when  the 
R/R  is  in  the  corresponding  state  as  specified 
by  data  word  I  (T6-0I)  bits  0-3.  In  the  Record  &  Play  state,  the 
percent  complete  applies  to  the  recording. 


WORD  NAME:  Internal  Memory/RMM  Size 


WORD  ID: 

T6-03 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

DESCRIPTION 

Bit  0  -  15  is  the  unsigned  integer  capacity  of  the 
Internal  Memory/RMM  in  Gigabytes 
(example:  64  =  64,000,000,000  bytes) 

4 

5 


BIT  NO. 

0  msb 

1 

2 
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6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


WORD  NAME:  Memory  Percent  Available 


WORD  ID: 

T6-04 

RANGE: 

0-100 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0  msb 
1 
2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


Bit  0  -  15  is  the  unsigned  integer  percent  of  unused  (available) 
storage  capacity  from  0  to  100  (0  =  full,  100  =  empty) 


WORD  NAME:  Number  of  Eiles 

WORD  ID:  T6-05  RANGE:  0-512 

SOURCE:  R/R  ACCURACY:  N/A 

DESTINATION:  BC  Isb:  N/A 
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XMIT  RATE  Periodic 

SIGNAL  TYPE  Discrete 

UNITS  N/A 

BIT  NO.  DESCRIPTION 


0  msb 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


Bit  0  -  15  is  the  unsigned  integer  number  of  files 
or  zero  if  no  RMM  is  mounted  in  the  R/R 


WORD  NAME  System  or  Replay  Time  Word  1 


WORD  ID: 

T6-06orT6-10 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE  Periodic 

SIGNAL  TYPE  Discrete 

UNITS  N/A 

BIT  NO.  DESCRIPTION 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 


msb 


Isb 

msb 


Isb 

msb 


Hex  Digit  #1  =  Tens  of  seconds,  binary  0  to  5 


Hex  Digit  #2  =  Units  of  seconds,  binary  0  to  9 


Hex  Digit  #3  =  Hundreds  of  milliseconds,  binary  0  to  9 
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11  isb  - 

12  msb  - 

13  Hex  Digit  #4  =  Tens  of  milliseeonds,  binary  0  to  9 

14 

15  isb  - 


WORD  NAME  System  or  Replay  Time  Word  2 


WORD  ID: 
SOURCE: 
DESTINATION: 
XMIT  RATE 
SIGNAE  TYPE 
UNITS 


T6-07orT6-ll 

R/R 

BC 

Periodic 

Discrete 

N/A 


RANGE:  N/A 

ACCURACY:  N/A 

Isb:  N/A 


BIT  NO. 

msb 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 


Isb 

msb 


Isb 

msb 


Isb 

msb 


Isb 


DESCRIPTION 


Hex  Digit  #1  =  Tens  of  hours,  binary  0  to  2^ 


Hex  Digit  #2  =  Units  of  hours,  binary  0  to  9^ 


Hex  Digit  #3  =  Tens  of  minutes,  binary  0  to  5 


Hex  Digit  #4  =  Units  of  minutes,  binary  0  to  9 


Note  1.  Hex  digit  #1  and  hex  digit  #2  (tens  of  hours  and  units  of  hours)  must  together  be  a 
decimal  number  from  00  to  23 


WORD  NAME  System  or  Replay  Time  Word  3 


WORD  ID: 

T6-08orT6-12 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 
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BIT  NO.  DESCRIPTION 

0  msb 

1 
2 

3  Isb 

4  msb 

5 

6 

7  Isb 

8  msb 

9 

10 

11  Isb 

12  msb 

13 

14 

15  Isb 

Note  1.  Hex  digit  #1  and  hex  digit  #2  (tens  of  months  and  units  of  months)  must  together  be  a 
decimal  number  from  01  to  12 

Note  2.  Hex  digit  #3  and  hex  digit  #4  (tens  of  days  and  units  of  days)  must  together  be  a 
decimal  number  from  01  to  31 

Note  3.  Hex  digit  #3  and  hex  digit  #4  (tens  of  days  and  units  of  days)  must  together  be  a  valid 
number  of  days  in  the  month  identified  by  hex  digit  #1  and  hex  digit  #2.  For 
example,  month  06  may  only  have  a  maximum  of  30  days. 


WORD  NAME  System  or  Replay  Time  Word  4 


WORD  ID: 

T6-09orT6-13 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO. 

DESCRIPTION 

0  msb 

1 

9 

Hex  Digit  #1  =  Thousands  of  years,  binary  0  to  2 

3  Isb 

4  msb 

5 

Hex  Digit  #2  =  Hundreds  of  years,  binary  0  to  9 

Hex  Digit  #1  =  Tens  of  months,  binary  0  to  1^ 


Hex  Digit  #2  =  Units  of  months,  binary  0  to  9' 


Hex  Digit  #3  =  Tens  of  days,  binary  0  to  3^’  ^ 


Hex  Digit  #4  =  Units  of  days,  binary  0  to  9^’  ^ 
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6 

7  isb  - 

8  msb  - 

9  Hex  Digit  #3  =  Tens  of  years,  binary  0  to  9 

10 

11  isb  - 

12  msb  - 

13  Hex  Digit  #4  =  Units  of  years,  binary  0  to  9 

14 

15  Isb  - 


WORD  NAME:  Number  of  BC  Events 


WORD  ID: 

T6-14 

RANGE: 

0-31 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAE  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


Bit  0  -  15  is  the  unsigned  integer  number  of  defined  BC  events 
from  0  to  3 1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15  Isb 


0  msb 
1 


WORD  NAME:  Eirmware  Version 


WORD  ID: 

T6-15 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 
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XMIT  RATE  Periodic 

SIGNAL  TYPE  Discrete 

UNITS  N/A 

BIT  NO.  DESCRIPTION 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 


msb  Bit  0  -  7  is  the  unsigned  integer  firmware  version  (major)  number 
Bit  0  is  msb,  Bit  7  is  Isb 


Bit  8  -  15  is  the  unsigned  integer  firmware  revision  (minor)  number 
Bit  8  is  msb,  Bit  15  is  Isb 


Isb 


WORD  NAME:  TMATS  Eile  Revision 


WORD  ID: 

T6-16 

RANGE: 

N/A 

SOURCE: 

R/R 

ACCURACY: 

N/A 

DESTINATION: 

BC 

Isb: 

N/A 

XMIT  RATE 

Periodic 

SIGNAL  TYPE 

Discrete 

UNITS 

N/A 

BIT  NO.  DESCRIPTION 


0  msb  Bit  0  -  15  is  the  unsigned  integer  TMATS  file  revision  number 

1 
2 

3 

4 

5 

6 

7 

8 

9 

10 
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11 

12 

13 

14 

15  Isb 


A.3.  Command  Acceptability  and  Validity 

After  boot-up,  the  R/R  is  always  operating  in  one  of  the  states  defined  herein.  The 
current  state  of  the  R/R  is  returned  in  the  STATUS  transmit  command.  The  acceptability 
(receive)  and  validity  (transmit)  of  each  of  the  commands  are  defined  in  Table  A- 3  as  follows. 

A  Always  acceptable  (receive)  or  valid  (transmit) 

1  Only  acceptable  when  an  volume  is  mounted  in  the  R/R 

2  INFO  (transmit)  validity  is  identified  by  the  validity  bits  in  word  1  and  word  10. 
STATUS  validity  is  identified  by  the  validity  bit  in  word  1. 

3  The  R/R  time  will  only  be  updated  by  the  TIME  command  when  the  Time  Channel 
synchronization  status  as  indicated  by  the  HEALTH  command  Time  Channel  status 
word  (Health  command  data  word  2  bit  11)  is  “synchronization  failure.” 

4  Applies  to  Stop  Command  with  Stop  Replay  option  only  when  Play  Live  Data  is 
active 

5  Applies  to  Replay  Command  with  Play  Live  option  only  when  Play  Live  Data  is  not 
active 

N  Never  acceptable  (receive)  or  valid  (transmit) 


When  the  R/R  receives  an  invalid  command,  it  will  remain  in  its  current  state  and  only 
set  the  “Last  Receive  Command  Error”  bit  in  the  STATUS  command  transmit  message  (T6-01 
bit  11). 


Table  A-3.  Military  Standard  1553  Command  Acceptability  and  Validity 

Command 

State 

BIT 

BUSY 

COMMAND 

ERROR 

DECLASSILY 

DECLASSILY 

ERROR 

DECLASSILY 

PASS 

ERASE 

HH 

< 

[In 

IDLE 

PLAY 

QUEUE  (LIND) 

RECORD 

RECORD  &  PLAY 

ASSIGN 

N 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

BIT 

N 

N 

A 

N 

A 

A 

N 

A 

A 

N 

N 

N 

N 

DECLASSILY 

N 

N 

1 

N 

1 

1 

N 

1 

1 

N 

N 

N 

N 

ERASE 

N 

N 

1 

N 

1 

1 

N 

1 

1 

N 

N 

N 

N 

EVENT  (RECV) 

N 

A 

A 

N 

A 

A 

N 

A 

A 

A 

A 

A 

A 
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EVENTS  (XMIT) 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

HEAETH 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

INEO  (RECV) 

N 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

INEO  (XMIT) 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

PAUSE 

N 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

QUEUE 

N 

I 

I 

N 

I 

I 

N 

I 

I 

N 

N 

I 

N 

RECORD 

N 

I 

I 

N 

I 

I 

N 

I 

I 

I 

I 

N 

N 

REPEAT 

N 

I 

I 

N 

I 

I 

N 

I 

5 

5 

N 

I 

5 

RESET 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

RESUME 

N 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

STATUS 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

STOP 

N 

N 

N 

N 

N 

N 

N 

N 

D 

A 

N 

A 

A 

SYNC 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

TIME 

N 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 
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APPENDIX  6-B 
Definitions 

Broadcasting:  Transmits  live  or  recorded  Chapter  10  data  packets  over  an  Ethernet  interface 
using  UDP  as  specified  by  Section  10.3  of  Chapter  10. 

Channel:  A  path  for  an  electrical  signal  interface  to  or  from  an  R/R.  Data  transported  into  or  out 
of  an  R/R  on  a  channel  are  not  in  Chapter  10  packets. 

Command  processor:  The  functional  part  of  an  R/R  that  accepts  operational  commands  into  its 
single  command  sequence. 

Command  sequence:  A  single  sequence  of  Chapter  6  commands  as  defined  in  this  standard. 

C&C:  Abbreviation  for  command  and  control  of  an  R/R  and  includes  status  reporting  and 
monitoring  of  the  R/R. 

Downloading:  Transfers  data  from  the  drive  attached  to  and  controlled  by  an  R/R  to  a  host 
computer  system. 

Drive:  An  electronic  or  electro-mechanical  drive  interface  used  to  transfer  data  to  or  from  a 

single  data  storage  device,  such  as  a  flash  disk,  rotating  disk,  CD,  or  DVD.  Supports  a 
single  fixed  or  removable  recording  medium. 

Feature:  A  data  input  or  output  channel,  a  packet  input  or  output  port,  a  drive,  or  the  R/R  itself. 
The  Chapter  6  health  monitoring  system  described  below  reports  information  about  each 
feature. 

File:  A  sequence  of  Chapter  10  packets  stored  on  a  storage  device  lAW  the  requirements  of 
Chapter  10. 

Looping:  An  operation  in  which  the  signals  connected  to  the  input  channels  are  reproduced  on 
the  output  channels  of  the  R/R.  During  looping  the  same  time  base  is  used  to  receive  and 
subsequently  transmit  one  or  more  data  streams. 

Circuit-looping:  Mode  of  operation  where  data  is  moved  from  the  input  channels  directly  to 
the  output  channels  with  minimum  latency  between  data  reception  and  data 
transmission. 

Drive-looping:  Mode  of  operation  where  received  data  is  first  written  to  one  or  more  drives 
and  subsequently  read  back  from  the  drive.  Drive-looping  may  or  may  not  include  a 
fixed  or  programmable  delay  between  the  time  data  is  written  to  and  read  from  drive. 

Health  attribute:  Each  feature  of  an  R/R  has  one  or  more  status  words  that  are  monitored 
through  the  health  reporting  system  described  in  this  standard. 

Mandatory  (M):  Required  capability  is  the  minimum  necessary  for  Major  Range  and  Test 

Eacility  Base  (MRTEB)  interoperability.  Units  that  do  not  meet  required  capability  are 
not  compliant. 

Optional  (O):  Optional  requirements  are  not  mandated  by  the  standard  and  are  not  necessary  for 
MRTEB  interoperability. 
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Port:  A  control  and/or  data  electrical  interface  to  an  R/R.  Data  transported  into  or  out  of  an  R/R 
on  a  port  is  wrapped  in  Chapter  10  packets. 

Pull-mode:  An  operational  mode  where  the  rate  at  which  data  is  received  and  processed  is 

determined  and  controlled  by  the  processing  algorithm.  A  pull-mode  operation  typically 
reads  previously  recorded  data  from  a  drive  device  at  the  rate  it  establishes  and  can 
support. 

Push-mode:  An  operational  mode  where  the  rate  at  which  the  data,  usually  live,  is  received  and 
processed  is  not  determined  or  controllable  by  the  processing  algorithm.  A  push-mode 
algorithm  must  “keep  up”  with  the  data  or  drop-outs  will  occur. 

R/R:  Recorder  and/or  reproducer  that  supports  a  single  command  sequence. 

Read-after- write:  An  operation  in  which  the  same  time  base  is  used  to  write  data  to  one  or  more 
drives  while  simultaneously  reading  all  or  a  subset  of  the  written  data  from  the  same 
drives.  Read- after- write  is  synonymous  with  drive-looping.  Read-after- write  can  be 
used  to  verify  accuracy  of  the  stored  data.  Data  recorded  erroneously  can  then  be 
rewritten  at  another  location. 

Read-while- write:  An  operation  in  which  separate  time  bases  are  used  to  write  data  to  one  or 
more  drives  while  simultaneously  reading  all  or  a  subset  of  the  written  data  from  the 
same  drives  from  random  locations. 

Recorder  Configuration  File:  Defines  the  structures  and  their  relationships  within  the  R/R  and 
to  configure  the  R/R  for  a  specific  operational  scenario.  The  recorder  configuration  file 
contains  the  payload  of  the  Chapter  10  computer- generated  data  packet.  Format  1  setup 
record  that  is  recorded  as  the  first  packet  of  each  compliant  Chapter  10  data  file. 

Recording:  Writes  live  push-mode  data  to  one  or  more  recording  drives. 

Recording  drive:  A  recording  medium  is  a  physical  unit  of  data  storage,  such  as  a  flash  disk, 
card,  DVD,  or  CD.  Recording  drives  may  or  may  not  be  removable  from  the  support 
electronics  that  connect  them  to  an  R/R.  A  removable  drive  is  referred  to  as  RMM  in 
Chapter  10. 

Reproducing:  Retrieves  previously  recorded  data  from  one  or  more  drives  and  outputs  the  data 
in  its  original  or  modified  format. 

Stream  (or  Channel  ID  Group):  The  set  or  a  named  subset  of  compliant  Chapter  10  packets 

produced  within  an  R/R.  A  single  stream  may  contain  either  live  or  recorded  packets,  but 
not  both.  The  default  stream  is  the  set  of  packets  produced  by  any  enabled  data  input 
channel  in  the  applicable  recorder  configuration  file.  A  named  stream  may  be  the  packets 
from  any  or  a  defined  subset  of  enabled  input  channels  in  the  applicable  configuration. 

Uploading:  Transfers  data  from  a  host  computer  system  into  the  drive  controlled  by  an  R/R. 

Volume:  A  logical  unit  of  data  storage  lAW  Chapter  10.  Each  volume  must  have  at  least  one 
compliant  directory  block  and  zero  or  more  compliant  data  files.  A  single  drive  may 
contain  one  or  more  volumes  (see  Chapter  10,  Subsection  10.5.1). 
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APPENDIX  6-C 
Citations 

National  Institute  of  Standards  and  Technology.  “Secure  Hash  Standard  (SHS).”  FIPS  PUB 

180-4.  August  2015.  May  be  superseded  by  update.  Retrieved  25  April  2017.  Available 
at  http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf. 
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Acronyms 


IP 

Internet  Protocol 

IPv4 

Internet  Protocol,  Version  4 

IPv6 

Internet  Protocol,  Version  6 

LLP 

low-latency  PTDP 

MAC 

media  access  control 

msb 

most  significant  bit 

PCM 

pulse  code  modulation 

PT 

packet  telemetry 

PTDP 

packet  telemetry  data  packet 

PTFR 

packet  telemetry  data  frame 

TmNS 

Telemetry  Network  Standard 
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CHAPTER  7 

Packet  Telemetry  Downlink 

This  standard  defines  the  method  for  transporting  variable-length,  well-defined  data 
formats  in  a  Chapter  4  pulse  code  modulation  (PCM)  stream. 

7.1  Packet  Telemetry 

Packet  telemetry  (PT)  defines  the  method  for  asynchronously  inserting  data  from  one  or 
more  data  streams  into  PCM  minor  frames.  This  standard  defines  various  PT  packet  types  that 
are  used  to  encapsulate  well-defined  data  formats,  including: 

•  Chapter  10  packets; 

•  Chapter  24  TmNSMessages; 

•  Ethernet  frames. 

A  PT  packet  is  encapsulated  into  an  integral  number  of  packet  telemetry  data  packets 
(PTDPs)  -  nominally  each  PTDP  contains  only  one  PT  packet.  Different  PT  packet  types  may 
be  multiplexed  simultaneously  into  a  single,  logical  stream  of  PTDPs,  which  is  then  segmented 
into  fixed-length  packet  telemetry  data  frames  (PTFRs)  that  are  inserted  into  a  PCM  stream. 
While  a  PTFR  may  be  segmented  and  interspersed  with  PCM  data  within  a  PCM  minor  frame, 
each  PCM  minor  frame  shall  contain  only  one  PTFR.  A  low-latency  PTDP  (FFP)  mechanism 
allows  for  the  insertion  of  one  or  more  PTDPs  with  low-latency  requirements  into  the 
transmission  of  a  long  PTDP.  Specific  structure-critical  elements  are  protected  using  a  Golay 
code;  see  Appendix  7- A  for  details.  Figure  7-1  provides  an  overview  of  the  entire  packet 
telemetry  encapsulation  process. 
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Figure  7-1.  Packet  Telemetry  Overview 


NOTE 


y 


A  PT  packet  may  be  fragmented  into  multiple  PTDPs  where  each  PTDP’s 
payload  contains  a  fragment  of  the  PT  packet.  Subsection  7.2.3  describes 
PT  packet  fragmentation. 


A  PTFR  may  be  segmented  for  insertion  into  a  PCM  minor  frame.  A  single 
PCM  minor  frame  may  contain  multiple  PTFR  segments.  See  Section  7^ 
for  more  details. 


NOTE 


y 


The  IRIG  106-15  restricted  a  PCM  minor  frame  to  a  single, 
complete  PTFR.  The  current  standard  supports  multiple  PTFR 
segments  per  PCM  minor  frame. 


NOTE^ 

Chapter  9  supports  defining  PTFR  segments  contained 

r 

within  a  PCM  minor  frame. 

7.2  Packet  Telemetry  Data  Packet  Structure 

A  PTDP  shall  include  a  header  and  a  payload  as  shown  in  Figure  7-2. 
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PTDP  HEADER 
(2x12  bits  unencoded  = 

2  X  24  bits  Golay-encoded) 
PTDP  PAYED AD 

_ (variable  length) _ 

Eigure  7-2.  PTDP  Structure 


7.2.1  PTDP  Header 

The  PTDP  header  shall  consist  of  two  12-bit  words  and  shall  be  encoded  as  two  24-bit 
Golay  code  words  prior  to  insertion  into  the  PTDP,  encoded  most  significant  bit  (msb)  first  and 
in  the  word  order  as  shown  in  Eigure  7-3. 


11  10 

9  8  7  6 

5  4 

3  2  10 

Word  0 

Reserved 

Content 

Pragment 

Eength  (15-12) 

Word  1 

Eength  (11-0) 

Eigure  7-3.  PTDP  Header  Structure  (Unencoded) 


The  PTDP  header  consists  of  the  following  fields. 

•  Reserved  (bits  23  -  22).  All  bits  shall  be  set  to  zero  (e.g.,  2’bOO)  on  transmission; 
ignored  on  reception. 

•  Content  (bits  21  -  18).  The  PT  packet  type  field  shall  specify  the  type  of  PTDP 
payload  (see  Subsection  7.2.2  for  details). 

o  4’bOOOO:  PT  Pill  Packet 

o  4’bOOOl:  PT  Application-Specific  Packet 

o  4’bOOlO:  PT  Test  Counter  Packet 

o  4’bOOll:  PT  Chapter  10  Packet 

o  4’bOlOO:  PT  Raw  Ethernet  Media  Access  Control  (MAC)  Prame  Packet 

o  4’bOlOl:  PT  Internet  Protocol  (IP)  Packet 

o  4’bOl  10:  PT  Chapter  24  TmNSMessage  Packet 

o  4’bOlll- 

4’bllll:  Reserved 


•  Pragment  (bits  17  -  16).  The  PT  packet  fragmentation  flags  shall  identify  whether 
the  PTDP  payload  contains  a  complete  PT  packet  or  a  fragment. 


o 

2’bOO: 

Complete  PT  Packet 

o 

2’bOl: 

Pirst  Pragment  of  a  PT  Packet 

o 

2’blO: 

Middle  Pragment  of  a  PT  Packet 

o 

2’bll: 

East  Pragment  of  a  PT  Packet 

•  Eength  (bits  15-0).  The  PTDP  length  field  shall  provide  the  length  (in  bytes)  of  the 
PTDP  payload  (note  the  PTDP  header  length  is  not  included  in  the  PTDP  length).  If 
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a  PT  packet  exceeds  the  maximum  PTDP  length,  the  PT  packet  must  be  fragmented 
using  multiple  PTDPs  as  specified  in  Subsection  123. 

1.12  PTDP  Payload 

The  PTDP  payload  shall  contain  either  a  complete  PT  packet  or  a  PT  packet  fragment 
and  the  Content  field  identifies  the  type.  The  following  subsections  contain  a  detailed 
description  for  each  PT  packet  type. 

7.2.2. 1  PT  Fill  Packet 

If  no  PT  packets  are  available  for  embedding  into  a  PTDP  stream,  PT  fill  packets  shall  be 
generated  and  inserted  into  the  PTDP  stream  to  assure  a  constant  data  flow  to  the  PCM  stream. 
Each  PT  fill  packet  byte  shall  be  set  to  8 ’b  10 10 10 10  (OxAA)  as  shown  in  Figure  7-4.  A  PT  fill 
packet  size  may  be  an  arbitrary  integral  number  of  bytes. 


7  0 

7  0 

7 

0 

7  0 

10101010 

(OxAA) 

10101010 

(OxAA) 

10101010 

(OxAA) 

hgure  7-4. 

^T  Fill  Packet 

1 2.12  PT  Application-Specific  Packet 

This  standard  does  not  define  the  format  of  PT  application-specific  packets.  While  PT 
application-specific  packets  are  allowed,  they  shall  not  be  used  to  encapsulate  data  that  conforms 
to  another  defined  PT  packet  format  (e.g..  Chapter  10  packets.  Chapter  24  TmNSMessages, 
Ethernet  data,  etc.). 

1 .1.1.3  PT  Test  Counter  Packet 

The  PT  test  counter  packet  is  defined  as  a  free-running  12-bit  counter.  The  PT  test 
counter  packet  shall  consist  of  one  12-bit  word  and  shall  be  encoded  as  one  24-bit  Golay  code 
word,  encoded  msb  first  as  shown  in  Figure  7-5. 


Figure  7-5.  PT  Test  Counter  Packet  (Unencoded) 


NOTE 


The  test  counter  packet  is  optional  and  this  standard  does  not 
specify  the  transmission  rate. 


7. 2. 2.4  PT  Chapter  10  Packet 

The  PT  Chapter  10  packet  structure  contains  a  slightly  modified  version  of  a  Chapter  10 
packet.  The  primary  differences  between  the  original  Chapter  10  packet  header  and  the  PT 
Chapter  10  header  are: 

•  The  PT  Chapter  10  packet  does  not  contain  the  packet  sync  pattern  field; 

•  The  PT  Chapter  10  packet  does  not  contain  the  packet  length  field; 

•  The  PT  Chapter  10  packet  contains  a  packet  trailer  bytes  field; 
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•  The  PT  Chapter  10  packet  may  contain  fewer  fill  bytes  than  the  original  Chapter  10 
packet  header. 

Subsection  7.2.2.4.1  describes  PT  Chapter  10  packet  composition.  Subsection  7. 2. 2.4. 2 
describes  Chapter  10  packet  reassembly. 

Figure  7-6  shows  the  Chapter  10  general  packet  structure  and  Figure  7-7  shows  the  PT 
Chapter  10  packet  structure. 


Chapter  10 
Packet 
Header 


31  24 

23  16 

15  8 

7  0 

Channel  ID 

Packet  Sync  Pattern 

Packet  Length 

Data  Length 

Data  Type 

Packet  Flags 

Sequence  Number 

Data  Type  Version 

Relative  i  ime  Counter  (low) 

1  leader  Checksum 

Relative  Time  Counter  (high) 

Packet  Secondary  Header  (optional) 

Packet  Body 

Packet  Trailer 

Figure  7-6.  Chapter  10  General  Packet  Structure 


PT 

Chapter  10 
Header 


PT  Chapter  10  Header  Protected  Fields 
(4x12  bits  unencoded  = 

4  X  24  bits  Golay-encoded) 

PT  Chapter  10  Header  Unprotected  Fields 
(12  bytes) 

Packet  Secondary  Header  (optional) 

Packet  Body 

Packet  Trailer 

Figure  7-7.  PT  Chapter  10  Packet  Structure 


The  original  Chapter  10  packet  header  fields  are  partitioned  into  two  groups  for  the  PT 
Chapter  10  header: 

•  Golay-encoded  protected  fields  that  protect  structure-critical  header  information; 

•  Unprotected  fields. 
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The  PT  Chapter  10  header  protected  fields  shall  consist  of  four  12-bit  words  and  shall  be 
encoded  as  four  24-bit  Golay  code  words  prior  to  insertion  into  the  PTDP  payload,  encoded  msb 
first  and  in  the  word  order  indicated  in  Figure  7-8. 


11  \  10  \  9  \  8  \  7 

6  \  5  \  4 

3  \  2  \  1  \  0 

Word  0 

Reserved  (0) 

Channel  ID  (15  -  12) 

Word  1 

Channel  ID  (1 1  -  0) 

Word  2 

Packet  Trailer  Bytes ^  (4  -  0) 

Data  Length^  (18-12) 

Word  3 

Data  Length^  (11-0) 

*  The  pac 
secondar} 
Subsectio 
^  The  Dat 
sizes,  exc 
Subsectio 

cet  trailer  bytes  shall  contain  the  sum  of  the  PT  Chapter  10  packet’s 
header  length,  fill  bytes  length,  and  packet  checksum  length.  See 
n7.2.2.4.1. 

a  Length  field  size  limit  of  19  bits  is  sufficient  for  all  Chapter  10  packet 
ept  Computer-Generated  Data  Packet,  Format  1  setup  record.  See 
n7.2.2.4.1. 

Figure  7-8.  PT  Chapter  10  Header  Protected  Fields  (Unencoded) 


The  PT  Chapter  10  header  unprotected  fields  shall  consist  of  12  bytes  as  shown  in  Figure 
7-9. 


31  24 

23  16 

15  8 

7  0 

Data  Type 

Packet  Flags 

Sequence 

Number 

Data  Type 
Version 

Relative  Time  Counter  (low) 

Header  Checksum 

Relative  Time  Counter  (high) 

Figure  7-9.  PT  Chapter  1C 

Header  Unprotected  Fields 

7. 2.2.4. 1  PT  Chapter  10  Packet  Composition 

The  following  steps  shall  be  executed  prior  to  constructing  a  PT  Chapter  10  packet. 

1 .  Truncate  the  number  of  packet  trailer  fill  bytes  to  no  more  than  three  bytes.  The 
number  of  fill  bytes  contained  in  a  PT  Chapter  10  packet  shall  be  restricted  to  a 
maximum  of  three  bytes. 

2.  Update  the  header  packet  length.  If  the  packet  trailer  fill  bytes  were  truncated,  the 
packet  length  shall  be  updated  accordingly. 

3.  Calculate  a  new  header  checksum.  If  the  packet  trailer  fill  bytes  were  truncated,  the 
header  checksum  shall  be  recalculated  using  the  updated  header  packet  length. 

4.  Calculate  a  new  data  checksum  (if  the  packet  trailer  contains  a  data  checksum).  If  the 
packet  trailer  fill  bytes  were  truncated  and  non-zero  packet  trailer  fill  bytes  were 
removed,  the  data  checksum  shall  be  recalculated  using  the  truncated  packet  trailer 
fill  bytes. 

Once  these  steps  are  executed,  the  Chapter  10  packet  header  shall  be  divided  into  the 
protected  and  unprotected  fields  as  described  above.  The  packet  trailer  bytes  field  shall  contain 
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the  sum  of  the  PT  Chapter  10  packet’s  secondary  header  length,  fill  bytes  length  (adjusted  to  a 
maximum  of  three  bytes),  and  data  checksum  length. 


If  the  size  of  the  Chapter  10  packet  exceeds  the  19 -bit  limit,  the  data  length  shall  be  set  to 
modulo  524,288  (2^^)  of  the  Chapter  10  packet  length  and  multiple  Chapter  10  PTDPs  shall  be 
generated  using  the  PT  packet  fragmentation  method  described  in  Subsection  123. 


NOTE 


5^ 


Compared  to  the  original  Chapter  10  packet,  the  resulting  PT  Chapter  10 
packet  is  either  identical,  or  due  to  fill  byte  truncation,  shorter  than  the  original 
Chapter  10  packet.  If  fill  byte  truncation  occurred,  the  packet  length  and 
packet  header  checksum  will  be  recalculated  and  the  data  checksum  may  be 
recalculated;  however,  the  PT  Chapter  10  packet’s  data  content  remains 
unchanged  from  the  original  Chapter  10  packet. 


7.2.2.4.2  Chapter  10  Packet  Reassembly 

A  Chapter  10  packet  may  be  reassembled  once  an  entire  PT  Chapter  10  packet  has  been 
reassembled  from  one  or  more  PTDPs  -  see  Subsection  7.2.3  for  details.  The  Chapter  10  packet 
header  shall  be  reassembled  after  Golay-decoding  is  performed  on  the  PT  Chapter  10  header’s 
protected  fields.  The  following  steps  shall  be  executed. 


1.  The  reassembled  Chapter  10  packet  sync  pattern  shall  be  set  to  0xEB25 
(16’bl  110101 100100101)  as  specified  in  Chapter  10. 

2.  The  reassembled  Chapter  10  packet’s  packet  length  shall  be  calculated  as  follows: 


Packet  Length  —  ^  (length  in  each  PTDP  Fragment  Header) 


3.  The  reassembled  Chapter  10  packet’s  data  length  shall  be  calculated  as  follows: 

Data  Length  =  calculated  Packet  Length  —  Packet  Header  Length  (24  bytes) 
—  Packet  Trailer  Bytes 

Perform  this  comparison  to  validate  the  reassembled  Chapter  10  packet’s  data  length: 


PT  Chapter  10  Packet's  Data  Length  =  calculated  Data  Length  modulo  524,288 


NOTE 


The  modulo  524,288  (2*^)  is  required  to  accommodate  original 
Chapter  10  packets  that  are  larger  than  524,288  bytes. 


The  following  steps  may  be  performed  to  verify  the  integrity  of  the  reassembled  Chapter 
10  packet. 

1 .  The  packet  header  checksum  should  be  calculated  and  compared  to  the  reassembled 
Chapter  10  packet  header  checksum. 


2.  If  present,  the  data  checksum  in  the  packet  trailer  should  be  calculated  and  compared 
to  the  reassembled  Chapter  10  packet  data  checksum  in  the  packet  trailer. 


NOTE 


If  fill  byte  truncation  occurred  during  PT  Chapter  10  packet  composition,  the 
reassembled  Chapter  10  packet  length  and  packet  header  checksum  will  differ 
and  the  data  checksum  may  differ  from  the  original  Chapter  10  packet; 
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however,  the  reassembled  Chapter  10  packet’s  data  content  remains  unchanged 
from  the  original  Chapter  10  packet. 


7. 2. 2. 5  PT  Raw  Ethernet  Media  Access  Control  Frame  Packet 

The  PT  raw  Ethernet  MAC  frame  packet  contains  one  physical-layer  MAC  frame, 
starting  with  the  MAC  destination  address  and  ending  with  the  frame  check  sequence  inclusive, 
as  shown  in  Figure  7-10.  The  PT  raw  Ethernet  MAC  frame  packet  can  contain  any  kind  of 
message  data,  IPv4,  IPv6,  and  jumbo  messages.  No  extra  protection  is  applied  to  the  PT  raw 
Ethernet  MAC  frame  packet. 


Destination 

Source 

EEC 

(opt) 

3-9  bytes 

Frame  Check 
Sequence 

4  bytes 

MAC 

MAC 

Ethertype 

Payload 

Address 

6  bytes 

Address 

6  bytes 

2  bytes 

46  -  1500  bytes 

Figure  7-10.  PT  Raw  Ethernet  MAC  Frame  Packet 


1 .2.2.6  PT  Internet  Protocol  Packet 

The  PT  IP  packet  contains  one  IPv4  as  shown  in  Figure  7-11  or  one  IPv6  packet  as 
shown  in  Figure  7-12.  No  extra  protection  is  applied  to  the  PT  IP  packet. 


IPv4  Header 

IPv4  Payload 

20-36  bytes 

20  -  65,536  bytes 

Figure  7- 1 1 .  PT  IPv4  Packet 


IPv6  Header 

IPv6  Payload 

40  bytes 

40  -  65,536  bytes 

Figure  7-12.  PT  IPv6  Packet 


1 .2.2.1  PT  TmNSMessage  Packet 

The  PT  TmNSMessage  structure  contains  a  slightly  modified  version  of  a  Chapter  24 
TmNSMessage.  Figure  7-13  shows  the  Chapter  24  TmNSMessage  structure  and  Figure  7-14 
shows  the  PT  TmNSMessage  packet  structure. 
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31  24 

23  16 

Oo 

TmNSMessage 

I  leader  — 

Mes.sage 

Version 

Option 

Word 

Count 

Reserved 

Message 

Type 

MessagcFlags 

MessagcDclinitionlD 

MessageDefinitionSequenceNumber 

McssagcLenglh 

McssagcTimcstamp  (64  bits) 

ApplicationDefinedTields  (optional,  variable  length) 

MessagePayload 

Figure  7-13.  Chapter  24  TmNSMessage  Structure 


PT 

TmNSMessage  — 

PT  TmNSMessage  Header  Proteeted  Fields 
(8x12  bits  uneneoded  = 

8  X  24  bits  Golay-eneoded) 

Header 

P  I  FmNSMessage  Header  Unprotected  Fields 
(12  bytes  +  ApplieationDelinedFields  length) 

MessagePayload 

Figure  7-14.  PT  TmNSMessage  Packet  Structure 


The  original  Chapter  24  TmNSMessage  header  fields  are  partitioned  into  two  groups  for 
the  PT  TmNSMessage  header: 

•  Golay-encoded  protected  fields  that  protect  structure-critical  header  information; 

•  Unprotected  fields  (those  fields  not  part  of  the  protected  fields). 

The  PT  TmNSMessage  header  protected  fields  shall  consist  of  eight  12-bit  words  and 
shall  be  encoded  as  eight  24-bit  Golay  code  words  prior  to  insertion  into  the  PTDP  payload, 
encoded  msb  first  and  in  the  word  order  shown  in  Figure  7-15. 
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11  \  10  \  9  \  8 

7  \  6  \  5  \  4  3  \  2  \  1  \  0 

Word  0 

Message  Version 

OptionWordCount  MessageFlags  (3  -  0) 

Word  1 

MessageFlags  (15-4) 

Word  2 

Reserved 

MessageDefinitionID  (31  -  24) 

Word  3 

MessageDefinitionID  (23  -  12) 

Word  4 

MessageDefinitionID  (11  -  0) 

Words 

MessageType 

MessageLength  (31  -24) 

Word  6 

MessageLength  (23  -  12) 

Word? 

MessageLength  (11-0) 

Figure  7-15.  PT  TmNSMessage  Header  Protected  Fields  (Unencoded) 

The  PT  TmNSMessage  header  unprotected  fields  shall  consist  of  12  bytes  plus  the 
ApplicationDefinedFields  (if  present)  as  shown  in  Figure  7-16. 

24  I  23_ 16  15_ 8  \  7_ 0 

MessageDefinitionSequenceNumber 

MessageTimestamp  (64  bits) 

ApplicationDefinedFields  (optional,  variable  length) 

Figure  7-16.  PT  TmNSMessage  Header  Unprotected  Fields 

7.2.3  PT  Package  Fragmentation 

If  a  PT  packet  requires  fragmentation,  each  PTDP  containing  a  PT  packet  fragment  shall 
be  inserted  sequentially  into  the  PTFR  stream.  Only  LLPs  can  be  inserted  in  between  a  PT 
packet’s  sequence  of  fragments  by  using  the  LLP  encapsulation  mechanism  as  described  in 
Subsection  7.4.2.  While  fragmentation  is  necessary  if  a  PT  packet’s  size  is  greater  than  or  equal 
to  64  kilobytes,  any  PT  packet  may  be  fragmented.  Figure  7-17  shows  PT  packet  fragmentation 
and  reassembly. 
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Figure  7-17.  PT  Packet  Fragmentation  and  Reassembly 


7.3  Packet  Telemetry  Data  Frame  Structure 

The  PTFR  is  a  fixed-length  frame  of  data  that  contains  a  portion  of  a  continuous  PTDP 
stream  as  represented  in  Figure  7-18. 


PTDP  Stream 

i  i 

1  TmNSMessage  j 

1  PT  Data  Packet  j 

Chapter  10 

PT  Data  Packet 

j  1  Ethernet  Frame 

1  1  PT  Data  Packet 

j  Chapter  10  j 

I  PT  Data  Packet  j 

^ / 

7\ 

7 

PTFR 

HDR 

PT  Data  Frame 
Payload 

PTFR 

HDR 

PT  Data  Frame  1 
Payload  1 

PTFR 

HDR 

PT  Data  Frame 
Payload 

I  PTFR 

1  HDR 

PT  Data  Frame  1 
Payload  1 

PTFR  Stream 

Figure  7-18.  Packet  Telemetry  Data  Frame  (PTFR)  Overview 


A  PTFR  consists  of  a  header  and  a  payload  as  shown  in  Figure  7-19. 


PTFR 

Header 


PTFR  Header,  Unprotected  Part 
(1  byte) 


PTFR,  Protected  Part 
(1x12  bits  unencoded  = 

1  X  24  bits  Golay-encoded) 


Figure  7-19.  PT  Data  Frame  Structure 


7.3.1  PTFR  Header 

The  PTFR  header  fields  are  partitioned  into  two  groups: 
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•  Unprotected  fields  that  contains  stream  and  version  information; 

•  Golay-encoded  protected  fields  that  protect  structure-critical  header  information. 

7 . 3 . 1 . 1  PTFR  Header  Unprotected  Fields 

The  PTFR  header  unprotected  fields  shall  consist  of  one  byte  as  shown  in  Figure  7-20. 


7 

6 

5 

4 

3 

2 

1 

0 

Stream  ID 

Reserved 

Version 

Figure  7-20.  PTFR  Header  Unprotected  Fields 


The  PTFR  header  unprotected  fields  are  defined  below. 

•  Stream  ID  (bits  7-4).  The  stream  ID  identifies  an  application-specific  stream. 

•  Reserved  (bits  3  -  2).  All  bits  shall  be  set  to  zero  (e.g.,  2’bOO)  on  transmission; 
ignored  on  reception. 

•  Version  (bits  1  -  0).  The  PTFR  version: 


o 

2’bOO: 

Version  I 

o 

2’bOI: 

Reserved 

o 

2’bIO: 

Reserved 

o 

2’bII: 

Reserved 

7 . 3 . 1 . 2  PTFR  Header  Protected  Fields 

The  PTFR  header  protected  fields  shall  consist  of  one  12-bit  word  and  shall  be  encoded 
as  one  24-bit  Golay  code  word  prior  to  insertion  into  the  PTDP  payload,  encoded  msb  first  and  in 
the  word  order  indicated  in  Figure  7-21. 


Figure  7-21.  PTFR  Header  Protected  Fields  (Unencoded) 

The  PTFR  header  protected  fields  are  defined  below. 

•  LL:  LLP  Exists  (bit  1 1)  -  see  Subsection  7.4.2  for  LLP  details 

o  I’bl:  indicates  the  PTFR  payload  contains  one  or  more  optional  LLPs  and  the 
closing  LLP  end  byte. 

o  I’bO:  indicates  no  LLP  and  no  LLP  end  byte  exist  in  the  PTFR  payload. 

•  Offset  to  First  PTDP  Header  (bits  10-0).  If  a  PTFR  contains  at  least  one  PTDP 
header,  this  field  specifies  a  byte  offset  to  the  first  byte  of  that  first  PTDP.  Otherwise, 
all  bits  shall  be  set  to  one  (1 1’bl  1 1 1 1 1 1 1 1 1 1).  The  value  is  relative  to  the  first  data 
byte  following  the  PTFR  header  (e.g.,  the  value  of  zero  represents  the  first  byte 
following  the  PTFR  header).  See  Subsection  7.4.1  for  additional  information. 
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7.3.2  PTFR  Payload 

The  PTFR  payload  contains  zero  or  more  partial  or  complete  PTDPs  as  illustrated  in 
Figure  7-22.  Optional  LLPs  may  be  inserted  in  the  PTFR  payload  after  the  PTFR  header  (see 
Subsection  7.4.2  for  LLP  details). 

LLP  1  (variable  size,  optional) 

LLP  1  End  Byte  (1  byte,  present  if  LLP  1  is  present) 


LLP  M  (variable  size,  optional) 

LLP  M  End  Byte  (1  byte,  present  if  EEP  M  is  present) 
Partial  or  Complete  PTDP  1  (variable  size) 
Complete  PTDP  2  (variable  size) 


Complete  PTDP  N-1  (variable  size) 

Complete  or  Partial  PTDP  N  (variable  size) 

Eigure  7-22.  PTER  Payload  Structure 

7.3.2. 1  Eow-Eatency  PTDP 

An  EEP  is  a  PTDP  having  low-latency  transmission  requirements  as  described  in 
Subsection  7.4.2.  If  one  or  more  EEPs  exist  in  a  PTER,  the  first  EEP  is  placed  immediately  after 
the  PTER  header. 

1 3.1.2  Eow-Eatency  PTDP  End  Byte 

Eor  each  EEP  contained  within  a  PTFR,  an  EEP  end  byte  shall  immediately  follow  the 
EEP.  The  EEP  end  byte  identifies  if  another  EEP  follows  or  if  this  is  the  last  EEP  in  the  PTER. 
The  EEP  end  byte  encoding  is  as  follows. 

•  8b’  11111111  (OxFF)  indicates  that  another  EEP  immediately  follows  this  byte. 

•  Sb’OOOOOOOO  (0x00)  indicates  there  are  no  more  EEPs  in  this  PTFR.  The  byte 
following  this  end  byte  is  the  first  byte  of  the  first  PTDP,  unless  the  EEP  end  byte 
is  the  PTER’s  last  byte  (i.e.,  there  are  no  PTDPs  in  the  PTER’s  payload). 

7.3.2.3  PTDPs  in  PTER  Payload 

The  PTER  payload  contains  zero  or  more  partial  or  complete  PTDPs  as  illustrated  in 
Eigure  7-22.  The  initial  and  last  PTDPs  may  be  either  partial  or  complete  PTDPs.  See 
Subsection  7.4.1  for  details. 

7.4  Asynchronous  PTDP  Multiplexing 

A  PTER  contains  asynchronously  inserted  PTDPs;  one  PTDP  may  span  multiple  PTERs. 
The  PTDP  stream  contains  a  continuous  series  of  PTDPs;  the  start  of  a  PTDP  must  immediately 
follow  the  last  byte  of  a  previous  PTDP  as  illustrated  in  Eigure  7-23. 
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_ start  n 

fPTD 
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' 

PTDP  Stream 
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i  i 

j  TmNSMessage  | 

j  PT  Data  Packet  | 

Chapter  10 

PT  Data  Packet 

j  1  Ethernet  Frame  1 
j  1  PT  Data  Packet  1 

j  Chapter  10  | 

j  PT  Data  Packet  | 

\  \ 

\ , 

r\ 

7\ 

7 

PTFR 

HDR 

PT  Data  Frame 
Payload 

PTFR 

HDR 

PT  Data  Frame 
Payload 

PTFR 

HDR 

PT  Data  Frame 
Payload 

I  PTFR 

HDR 

PT  Data  Frame  1 
Payload  1 '  " 

PTFR  Stream 


Figure  7-23.  Start  of  PTDPs  Overview 


7.4.1  Standard  PTDP  Encapsulation 

If  the  start  of  a  PTDP  is  contained  within  a  PTFR,  the  PTFR  header  shall  contain  the 
offset  to  the  PTDP’s  first  byte.  If  there  are  multiple  PTDPs  in  the  PTFR,  the  PTFR  header  shall 
contain  the  offset  to  the  start  of  the  first  PTDP.  Since  one  PTDP  may  span  multiple  PTFRs,  the 
PTFR  header  may  not  contain  an  offset  to  a  PTDP.  See  Subsection  7.3. 1.2  for  details.  An 
overview  of  the  standard  PTDP  encapsulation  mechanism  is  shown  in  Figure  7-24. 


Figure  7-24.  Standard  PTDP  Encapsulation  Overview 
7.4.2  Low-Latency  PTDP  Encapsulation 

The  transmission  of  a  long  PTDP  may  cause  too  long  of  latency  for  some  critical  data. 
Therefore,  an  LLP  mechanism  is  provided,  allowing  the  insertion  of  one  or  more  PTDPs  with 
low-latency  requirements  within  the  transmission  of  a  long  PTDP.  The  interrupted  long  PTDP  is 
resumed  immediately  after  the  LLP  part  of  the  PTLR. 

An  LLP  shall  not  span  multiple  PTLRs.  When  constructing  a  PTLR,  an  entire  LLP  and 
associated  end  byte  shall  fit  into  the  remaining  space  in  the  PTLR.  Ligure  7-25  shows  an 
overview  of  PTDP  encapsulation  with  LLPs. 


7-14 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  7,  July  2017 


JSOTE/% 

The  offset  to  the  first  PTDP  in  the  PTFR  header  is  not 

r 

necessarily  pointing  immediately  after  the  LLP. 

7.5  PT  Data  Frame  Transport 

To  insert  a  PTFR  into  a  Chapter  4  PCM  minor  frame,  each  PTFR  segment  is  byte-aligned 
and  inserted  into  the  PCM  minor  frame  as  a  byte  stream  with  the  msb  first  (as  shown  in  Figure 
7-26).  If  a  PTFR  segment’s  size  is  not  an  integral  number  of  bytes,  the  remaining  bits  at  the  end 
of  the  PTFR  segment  are  considered  fill  bits  and  should  be  ignored.  Each  PCM  minor  frame 
shall  contain  exactly  one  complete  PTFR  structure;  Figure  7-27  shows  a  PCM  minor  frame  with 
two  PTFR  segments. 
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Figure  7-27.  PCM  Minor  Frame  With  Two  PTFR  Segments 


If  no  PTDPs  are  available  for  transmission,  PTDPs  with  PT  fill  packets  shall  be  inserted 
into  the  PTFR  for  subsequent  insertion  into  the  PCM  minor  frame. 


NOTE 


All  PCM  minor  frame  overhead  words  such  as  the  Chapter  4  sync 
pattern  or  subframe  counters  are  not  considered  part  of  a  PTFR. 
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APPENDIX  7-A 

Extended  Binary  Golay  Code 


A.l.  Introduction 

A  single-bit  transmission  error  may  cause  excessive  data  loss  in  packet  telemetry.  If  the 
error  occurs  in  identification  or  structure  length  fields,  the  error  can  lead  to  misinterpretation  of  a 
packet  or  a  loss  of  a  series  of  packets. 

To  help  mitigate  potential  errors,  a  self-correcting  coding  called  extended  binary  Golay 
code  is  applied  to  structure-critical  elements  in  a  packet  telemetry  stream.  This  additional  coding 
provides  protection  of  the  packet  identification  and  length  information  and  supports  correction  of 
up  to  3-bit  transmission  errors  in  a  24-bit  sequence.  This  is  accomplished  by  encoding  12-bit 
words  into  24-bit  words. 

This  extended  binary  Golay  code,  G24  (sometimes  just  called  the  “Golay  code”  in  finite 
group  theory)  encodes  12  bits  of  data  in  a  24-bit  word  in  such  a  way  that  any  3-bit  errors  can  be 
corrected  or  any  7-bit  errors  can  be  detected.  In  standard  code  notation  the  codes  have 
parameters  (24,  12,  8)  corresponding  to  the  length  of  the  code  words,  the  dimension  of  the  code, 
and  the  minimum  Hamming  distance  between  two  code  words,  respectively.  ^  The  coding  and 
decoding  of  the  Golay  code  is  illustrated  in  Figure  A-1. 


Figure  A- 1 .  Golay  Code  Encoding  and  Decoding 


The  following  sections  are  C  code  reference  implementation  and  define  the  required 
behavior  of  encoding  and  decoding  the  extended  binary  Golay  code. 


'  Golay,  Marcel  J.  E.  Notes  on  Digital  Coding  in  “Proceedings  of  the  IRE,”  1949,  v.37,  p.  657. 
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A.2.  Encoding  Golay  Code 

The  extended  binary  Golay  code  encoding  lookup  table  can  be  initialized  by  the 
InitGolayEncodeO  function,  and  the  encoding  can  be  done  by  the  Encode(v)  macro  of  the 
following  C  code. 

#define  GOLAY_SIZE  0x1000 


//  Generator  matrix  :  parity  sub-generator  matrix  P  : 


uintl6_t  G_P[12]  =  { 

0xc75,  0x63b,  0xf68,  0x7b4, 
0x3da,  0xd99,  0x6cd,  0x367, 
0xdc6,  0xa97,  0x93e,  0x8eb 

}; 


/*  Binary  representation 


1 

1 

0 

0 

0 

1 

1 

1 

0 

1 

0 

1 

0 

1 

1 

0 

0 

0 

1 

1 

1 
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1 

1 

1 

1 

1 

1 

0 

1 

1 

0 

1 

0 

0 

0 

0 

1 

1 

1 

1 

0 

1 

1 

0 

1 

0 

0 

0 

0 

1 

1 

1 

1 

0 

1 

1 

0 

1 

0 

1 

1 

0 

1 

1 

0 

0 

1 

1 

0 

0 

1 

0 

1 

1 

0 

1 

1 

0 

0 

1 

1 

0 

1 

0 

0 

1 

1 

0 

1 

1 

0 

0 

1 

1 

1 

1 

1 

0 

1 

1 

1 

0 

0 

0 

1 

1 

0 

1 

0 

1 

0 

1 

0 

0 

1 

0 

1 

1 

1 

1 

0 

0 

1 

0 

0 

1 

1 

1 

1 

1 

0 

1 

0 

0 

0 

1 

1 

1 

0 

1 

0 

1 

1 

*/ 

uint32_t  EncodeTable [  GOLAY_SIZE  ];  //  Golay  encoding  table 

//  encode  a  12-bit  word  to  a  24-bit  Golay  code  word 
#define  Encode (v)  EncodeTable [v&Oxfff] 


//  initialize  the  Golay  encoding  lookup  table 
void  InitGolayEncode (  void  ) 

{ 


f or (  uint32_t  x=0;  x  <  GOLAY_SIZE;  x++  )  { 

//  generate  encode  LUT 
EncodeTable [x]  =  (x<<12)  ; 

for (  uint32_t  i=0;  i<12;  i++  )  { 

if (  (x>>  (11-i) )  &  1  ) 

EncodeTable [x]  G_P[i]; 


A.3.  Decoding  Golay  Code 

The  extended  binary  Golay  code  decoding  lookup  tables  can  be  initialized  by  the 
InitGolayDecodeO  function  of  the  following  C  code.  The  12-bit  decoded  and  corrected  word 
can  be  calculated  by  the  Decode(v)  macro  from  a  24-bit  code  word.  The  number  of  error  bits  in 
a  24-bit  code  word  can  be  gotten  by  the  Error(v)  macro  from  a  24-bit  code  word. 
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#def ine 


GOLAY  SIZE 


0x1000 


uintl6_t  SyndromeTable [  GOLAY_SIZE  ]; 
uintl6_t  CorrectTable [  GOLAY_SIZE  ]; 
uint8_t  ErrorTable[  GOLAY_SIZE  ]; 


/ /  Syndrome  table 
//  correction  table 
//  number  of  error  bits  table 


#define  Syndrome2 (vl ,  v2 ) 
#define  Syndrome (v) 
#define  Errors2 (vl , v2 ) 
#define  Decode2 (vl , v2 ) 


(SyndromeTable [v2] ^ (vl) ) 

Syndrome2 ( ( (v) >>12) &0xfff , (v) &0xfff ) 
ErrorTable [ Syndrome 2 ( vl , v2 ) ] 

( ( vl ) ^CorrectTable [ Syndrome2 (vl , v2 ) ] ) 


//  get  the  number  of  error  bits  in  this  24-bit  code  word 
#define  Errors (v)  Errors2 ( ( (v) >>12) SOxfff , (v)&0xfff) 

//  get  the  12-bit  corrected  code  from  a  24-bit  code  word 
#define  Decode (v)  Decode2 ( ( (v) >>12) sOxfff , (v) sOxfff ) 

//  Parity  Check  matrix 
uintl6_t  H_P[12]  =  { 

0xa4f,  0xf68,  0x7b4,  0x3da, 

Oxled,  0xab9,  0xfl3,  0xdc6, 

0x6e3,  0x93e,  0x49f,  0xc75 


/*  Binary  representation 


0  10 
111 


0  111 
0  0  11 


0  10  0 
0  110 
10  11 
110  1 


1111 
10  0  0 
0  10  0 
10  10 


0  0  0  1 
10  10 


1  1 
0  1 


1110 
10  11 
0  0  0  1 
110  0 


110  1 
10  0  1 
0  0  11 
0  110 


0  110 
10  0  1 
0  10  0 
110  0 


1110 
0  0  11 
10  0  1 
0  111 


0  0  11 
1110 
1111 
0  10  1 


//  calculate  the  number  of  Is  in  a  24-bit  word 
uint8_t  OnesInCode (  uint32_t  code,  uint32_t  size 
{ 

uint8_t  ret  =  0; 

for (  uint32_t  1=0;  i<size;  i++  )  { 

if (  (code>>i)  &  1  ) 
ret++; 


return  ret; 


void  InitGolayDecode (  void  ) 

{ 

f or (  uint32_t  x=0;  x  <  GOLAY_SIZE;  x++  )  { 

/ /  generate  syndrome  LUT 
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SyndromeTable [x] =0;  //  Default  value  of  the  Syndrome  LUT 

for (  uint32_t  1=0;  i<12;  i++  )  { 

If (  (x>>(ll-i))  &  1  )  SyndromeTable [x]  H_P[i]; 

ErrorTable [x]  =  4 ; 

CorrectTable [x] =0xf f f  ; 


//  no  error  case 
ErrorTable [ 0 ]  =  0; 

CorrectTable [ 0 ] =  0; 

//  generate  all  error  codes  up  to  3  ones 
for  (  int  1=0;  i<24;  i++  )  { 

for (  Int  j=0;  j<24;  j++  )  { 

for (  Int  k=0;  k<24;  k++  )  { 

uint32_t  error  =  {l<<i)  |  {l<<j)  |  (l<<k); 

uint32_t  syndrome  =  Syndrome (error ) ; 
CorrectTable [ syndrome ]  =  {error>>12)  &  Oxfff; 
ErrorTable [ syndrome ]  =  OnesInCode (error, 24 ) ; 


A.4.  Decoding  the  Golay  Code  (8,1,3) 

The  one-byte  0x00  or  Oxff  can  also  be  considered  as  a  binary  Golay  code  (8,1,3)-  It 
allows  correcting  the  0x00  or  Oxff  transmission  of  up  to  3-bit  errors,  and  detecting  4-bit  errors. 
The  (8,1,3)  code  decoding  lookup  tables  shall  be  initialized  by  the  InitGolay00FFDecode() 
function,  and  the  decoding  can  be  done  by  the  DecodeOOFF(v)  macro  of  the  following  C  code. 

#deflne  BYTE_LUT_SIZE  0x100 

uint8_t  DecodeOOFFTable [  BYTE_LUT_SIZE  ];  //  decode  0x00  or  Oxff  (8,1,3) 
uint8_t  ErrorOOFFTable [  BYTE_LUT_SIZE  ];  //  number  of  error  bits  (8,1,3) 

#define  DecodeOOFF (v)  DecodeOOFFTable [v] 

#define  ErrorOOFF (v)  ErrorOOFFTable [v] 

void  InitGolayOOFFDecode  (  void  ) 

{ 

//  generate  (8,1,3)  tables 
for(  uint32_t  1=0;  i<BYTE_LUT_SIZE;  i-i-i-  )  { 
uint32_t  j  =  OnesInCode(i,8); 

Decode00FFTable[i]  =  j  <=  4  ?  0  :  0xff; 

Error00FFTable[i]  =  j  <=  4  ?  j  :  8-j; 

} 

} 
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*  *  *  END  OF  CHAPTER  1  *** 
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Acronyms 


ARINC 

Aeronautical  Radio,  Incorporated 

CRC 

cyclic  redundancy  check 

FCS 

frame  check  sequence 

HDDR 

high-density  digital  recording 

MIL-STD 

Military  Standard 

msb 

most  significant  bit 

PCM 

pulse  code  modulation 

RNRZ-1 

randomized  non-return-to-zero-level 
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CHAPTER  8 

Digital  Data  Bus  Acquisition  Formatting  Standard 


8.1  General 

This  standard  describes  output  data  formats  for  the  acquisition  of  all  the  traffic  flowing 
on  various  digital  data  buses.  The  formats  permit  the  capture  of  data  from  multiple  data  buses 
within  a  single  system.  Other  constraints,  such  as  radio  frequency  bandwidth  and  tape  recording 
time,  will  dictate  the  actual  number  of  buses  processed  by  a  single  system.  Standards  for  both 
composite  telemetry  pulse  code  modulation  (PCM)  and  tape  recorder  PCM  formats  are 
presented. 

Although  specifically  designed  to  satisfy  the  requirements  of  100  percent  Military 
Standard  (MIL-STD)  1553  bus  and  Aeronautical  Radio,  Incorporated  (ARINC)  429  channel 
acquisition,  the  formatting  provisions  of  this  standard  may  be  used  in  other  applications  when  the 
data  source  and  content  are  similar  enough  to  permit  easy  adaptation.  Users  should  contact  the 
appropriate  range  to  ensure  any  adaptations  are  compatible  with  that  range. 

In  addition  to  the  total  data  capture  technique  and  format  presented  in  this  chapter, 
“Selected  Measurement”  methods  are  available  to  acquire  less  than  100  percent  of  bus  data. 
Selected  Measurement  methods  result  in  PCM  formats  conforming  to  Chapter  4  and  fall  outside 
the  scope  of  this  chapter. 

This  chapter  presents  the  general  requirements  for  data  formatting  followed  by  individual 
sections  addressing  specifics  pertaining  to  MIL-STD-1553  and  ARINC  429  respectively. 


8.2  Word  Structure 

The  following  subparagraphs  describe  the  general  word  structure  to  be  used  for  the 
formatted  output.  Specific  word  structures  and  definitions  are  provided  as  part  of  each 
bus/channel  subsection. 


8.2.1  Field  Definition 


The  formatted  data  shall  be  a  24-bit  word  constructed  as  shown  in  Table  8-1. 


Table  8-1. 

Word  Construction 

Bit  Position 

1 

2  3  4 

5  6  7  8 

9  10  11  12  .  .  .  21  22  23  24 

P 

Bus  / 

Content 

A 

Group 

Ident 

INFORMATION 

R 

I 

T 

Y 

Ident 

Label 

Or 

Label 

Content 

Bus  Ident  Label 


A.  Field  Definition 
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Bit  Bit 


1  2 

3 

4 

1  2 

3 

4 

0  0 

0 

0 

Bus  /  Group  1 

1  0 

0 

0 

Bus  /Group  9 

0  0 

0 

1 

Bus  /  Group  2 

1  0 

0 

1 

Bus  /Group  10 

0  0 

1 

0 

Bus  /  Group  3 

1  0 

1 

0 

Bus  /Group  1 1 

0  0 

1 

1 

Bus  /  Group  4 

1  0 

1 

1 

Bus  /Group  12 

0  1 

0 

0 

Bus  /  Group  5 

1  1 

0 

0 

Bus  /Group  13 

0  1 

0 

1 

Bus  /  Group  6 

1  1 

0 

1 

Bus  /Group  14 

0  1 

1 

0 

Bus  /  Group  7 

1  1 

1 

0 

Bus  /Group  15 

0  1 

1 

1 

Bus  /  Group  8 

1  1 

1 

1 

Bus  /Group  16 

B.  Bus/Group  Identification  Label  Definition;  Bits  (1)  2,  3,  &  4 


Bit 

5  6  7  8 

1111 
1110 
110  1 
110  0 
10  11 
10  10 
10  0  1 
10  0  0 


Bit 

5  6  7  8 

0  111  Time  -  High  Order 

0  110  Time  -  Low  Order 

0  10  1  Time  -  Microsecond 

0  10  0  Application  Specific 

0  0  11  User  Defined 

0  0  10  User  Defined 

0  0  0  1  Fill  Word 

0  0  0  0  Buffer  Overflow 

C.  Content  Identification  Label  Definition;  Bits  5,  6,  7,  &  8 


The  function 
of  these  codes 
is  dependent 
on  the  bus 
type  being 
monitored. 


8.2.2  Most  Significant  Bit 

The  most  significant  bit  (msb)  (bit  1)  of  each  formatted  word  may  optionally  be  an  odd 
parity  bit  generated  for  the  resulting  formatted  word  or  an  additional  bit  appended  to  the 
bus/group  identification  label  as  described  in  Paragraph  8.2.3. 

8.2.3  Bus/Group  Identification  Label 

Each  word  shall  also  carry  a  bus  or  group  identification  label  as  shown  in  Table  8-1.  For 
this  application,  a  bus  refers  to  a  MIL-STD-1553  bus  (or  dual  redundant  bus  pair)  and  a  group 
refers  to  a  collection  of  up  to  four  ARINC  429  channels.  The  bus/group  identification  label  may 
optionally  be  three  or  four  bits  in  length  dependent  on  the  exercise  of  the  option  to  use  or  not  use 
a  parity  bit.  If  not  used,  the  parity  bit,  or  bit  1,  is  appended  to  the  bus/group  identification  label 
to  increase  the  bus  count  from  a  maximum  of  eight  (3  bits)  to  a  maximum  of  16  (4  bits). 

8.2.4  Content  Identification  Label 

Each  incoming  bus  word,  auxiliary/user  input,  or  time  word  shall  be  appropriately  labeled 
with  a  4-bit  content  identification  label  (see  Table  8-1).  Content  identification  labels  are  specific 
to  each  bus  type  and  are  detailed  in  later  sections. 

8.2.5  Information  Content  Field 

Data  extracted  from  the  data  bus  shall  maintain  bit  order  integrity  and  be  inserted  into  the 
information  content  field  as  specified  for  each  bus  type.  Transposing  or  reordering  of  the  bits  is 
not  permitted. 
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8.2.6  Fill  Words 

Fill  words,  required  to  maintain  continuous  PCM  output,  shall  have  the  following 
sequence  as  the  information  content  pattern: 

1010  1010  1010  1010  (AAAA  hexadecimal) 


8.2.7  Content  Identification  Label 

The  content  identification  label  indicating  buffer  overflow  (0000)  and  appropriate 
bus/group  identification  label  tag  shall  be  appended  to  the  first  word  placed  into  the  buffer  after 
the  buffer  becomes  available  for  data  storage.  This  word  should  be  an  extra  word,  not  the  next 
available  piece  of  data.  Bits  9  through  24  are  available  for  system  level  diagnostics  and  are  not 
specified  here.  Tagging  in  this  manner  marks  the  point  of  data  discontinuity  and  preserves  the 
integrity  of  the  next  piece  of  data. 

8.2.8  Cyclic  Redundancy  Check 

Cyclic  redundancy  check  (CRC)  is  a  very  powerful  technique  for  obtaining  data  quality. 
An  optional  CRC  word  may  be  appended  as  the  last  positional  word  of  each  PCM  frame  (see 
Figure  8-2).  The  CRC  word  shall  be  composed  of  parity  and/or  bus/group  identification  label, 
content  identification  label,  and  16  bits  of  a  frame  check  sequence  (FCS).  The  FCS  shall  fill  the 
information  content  field  (bits  9  -  24).  The  following  CRC- 16  polynomial  shall  be  used  to 
generate  the  FCS.  None  of  the  24  bits  making  up  the  entire  CRC  word  shall  be  used  in  the 
calculation  of  the  16-bit  FCS. 


CRC- 16  polynomial:  X16-I-X15-I-  X2  -i-  1 


NOTE 


Exercise  care  when  assigning  bus  identification  and  content  identification 
label  codes  to  the  CRC  word.  Although  a  positional  word  in  the  frame, 
legacy-processing  algorithms  may  falsely  identify  the  information  if  one  of 
the  bus  data  labels  (1111  -  1000)  is  used  as  the  content  identification  label. 


8.3  Time  Words 

The  following  describes  the  structure  and  use  of  time  words  within  the  formatted  output. 

The  time  words  dedicated  to  providing  timing  information  are  defined  in  Chapter  4. 
These  time  words  are  designated  as  high  order  time,  low  order  time,  and  microsecond  time.  The 
MIL-STD-1553  bus  data  acquisition  applications  use  an  optional  fourth  time  word,  designated  as 
response  time.  The  response  time  word  has  the  same  structure  as  the  microsecond  time  word. 
Time  word  structure  shall  follow  the  16-bit  per-word  format  shown  in  Chapter  4,  Figure  4-4,  and 
be  placed  into  the  information  content  field  (bits  9  through  24)  in  bit  order. 

8.4  Composite  Output 

8.4.1  Characteristics  of  a  Singular  Composite  Output  Signal 

The  following  subparagraphs  describe  the  characteristics  for  a  singular  composite  output 

signal. 

a.  The  composite,  continuous  output  shall  conform  to  the  requirements  for  Class  2  PCM  as 
stated  in  Chapter  4. 
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b.  The  data  shall  be  transmitted  msb  (bit  1)  first. 

c.  The  bit  rate  is  dependent  on  several  factors  including  bus  loading  and  auxiliary  inputs  and 
shall  be  set  to  a  fixed  rate  sufficient  to  preclude  any  loss  of  data. 

d.  The  order  of  bus  words  must  remain  unaltered  except  in  the  case  of  a  buffer  overflow. 

e.  The  frame  length  shall  be  fixed  using  fill  words  as  required  and  shall  be  >  128  words  and 
<512  words  including  the  frame  synchronization  word. 

f.  The  frame  synchronization  word  shall  be  fixed  and  24  consecutive  bits  in  length.  The 
pattern,  also  shown  in  Chapter  4  Appendix  4- A,  Table  A-1,  is: 

1 1 1 1  1010  1 1 1 1  001 1  0010  0000  (FAF320  hexadecimal). 

g.  A  frame  structure  employing  frame  time  is  recommended  but  optional.  If  frame  time  is 
used,  the  frame  structure  shall  consist  of  the  frame  synchronization  word,  followed  by  the 
high  order  time  word,  followed  by  the  low  order  time  word,  followed  by  the  microsecond 
time  word,  followed  by  the  data  words  from  all  sources  making  up  the  composite  signal 
up  to  the  frame  length  specified  in  item  e  above  (also  see  Figure  8-1).  If  frame  time  is 
not  used,  the  frame  synchronization  word  shall  be  followed  immediately  by  the  data 
words.  If  a  CRC  word  is  not  used,  the  last  word  in  the  frame  is  data  word  N. 


FRAME  STOC 
PA'rrHRN 

FRAME 
HKiH  I'lMK 

FRAME 
TOW  TIME 

FRAME 
MICRO  riMK 

D.VTA 

WORD  1 

D.VTA 

DATA 

D.VTA 

CRC 

WORD  N-2 

WORDN-1 

WORD  N 

(OPTION.U.) 

_ END  OF  FRAME _  ' 

Figure  8-1.  Composite  Frame  Structure 

h.  The  following  describes  the  recommended  techniques  for  recording  the  composite  output 

signal. 

(1)  Longitudinal  recording  shall  conform  to  the  PCM  recording  provisions  Annex  A. 2. 

(2)  Recording  using  parallel  high-density  digital  recording  (HDDR)  or  rotary  head 
recorders  offers  the  advantage  of  inputting  a  single  high  bit  rate  signal  to  the 
recording  system.  The  input  PCM  signal  shall  conform  to  the  appropriate  sections 
of  this  standard. 

(3)  If  recording  using  digital  recorders  or  other  non-continuous  recording  processes 
with  buffered  inputs,  the  fill  words,  inserted  to  provide  a  continuous  output  stream, 
may  be  eliminated. 
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NOTE 


Additional  care  must  be  exercised  in  data  processing  and  reduction  if 
the  last  word  in  a  composite  stream  is  a  MIL-STD-1553  command 
word.  The  associated  message  time  tag  will  not  appear  until  after  the 
synchronization  and  time  words  in  the  next  frame. 


8.5  Single  Bus  Track  Spread  Recording  Format 

8.5.1  Single  Bus  Recording  Technique  Characteristics 

The  following  subparagraphs  describe  the  characteristics  of  a  single  bus  recording 
technique  using  a  multiple  tape  track  spread  output  format. 

a.  The  target  tape  recorder/reproducer  for  a  track  spread  format  is  a  longitudinal  fixed-head 
machine  described  in  Annex  A. 2  and  not  one  employing  parallel  HDDR  or  rotary  head 
recording  characteristics. 

b.  The  code  generated  for  longitudinal  tape  recording  shall  be  randomized  non-return-to- 
zero-level  (RNRZ-L)  or  bi-phase-level  as  described  in  Chapter  4  and  Annex  A. 2. 


NOTE^ 

Bit  rates  less  than  200,000  bits  per  second  are  not 

r 

recommended  when  using  RNRZ-L. 

c.  To  extend  recording  time  while  still  acquiring  100  percent  of  bus  data,  a  multiple  track 
spread  recording  technique  is  presented  as  follows. 


(1)  When  necessary  to  use  more  than  one  tape  recording  track  (to  extend  record  time), 
separate  PCM  streams  shall  be  created  and  delayed  by  24/TK  bits  with  respect  to 
each  other,  where  TK  represents  the  number  of  tape  tracks  used  for  a  given  bus. 


(2) 


When  multiple  track-spread  recording  is  required,  the  track  spread  shall  be  on  a  bus 
basis  such  as  bus  number  1  spread  over  four  tracks,  and  bus  number  2  spread  over 
two  tracks.  The  maximum  number  of  tracks  per  bus  shall  be  limited  to  four. 


NOTE 


Y 


Consideration  should  be  given  to  spread  track 
assignment.  All  tracks  associated  with  a  given  bus 
should  be  recorded  on  the  same  head  stack. 


(3)  Each  stream  shall  have  a  frame  synchronization  pattern  24  bits  in  length, 
conforming  to  item  f  of  Subsection  8.4.1. 

(4)  The  word  structure  shall  be  identical  to  that  described  in  Paragraph  8.2. 

(5)  The  frame  length  shall  be  fixed  and  shall  be  the  same  for  each  track  used  for  a 
given  bus.  The  frame  length  shall  conform  to  the  requirements  of  item  e  in 
Subsection  8.4.1. 

(6)  The  data  shall  be  formatted  such  that  it  is  transmitted  (recorded)  msb  (bit  1)  first. 

(7)  The  use  of  a  CRC  word  as  described  in  Subparagraph  8.2.8  is  optional.  If  used  in 
the  track  spread  application,  a  CRC  word  must  be  generated  and  appended  to  each 
of  the  PCM  frames  for  that  bus. 
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(8)  A  Structure  employing  frame  time  is  recommended  but  optional.  The  following 
describes  a  four-track  spread  example  using  frame  time. 

•  TKl.  The  PCM  stream  designated  TKl  shall  be  constructed  as  the  frame 

synchronization  word,  followed  by  the  high  order  frame  time  word,  followed  by 
data  words  (see  Figure  8-2). 


TKl 


■|’K2 


TK3 


TK4 


FRAMH  SYNC 

FRAMH 

DATA 

DA'l’A 

PATTERN 

HIGH  TIME 

WORD  2 

WORD  6 

FRAMH  SYNC 

FRAMH 

DATA 

DATA 

PATTERN 

LOW  TIME 

WtiRD  3 

WORD  7 

24  I  K  bit  times 


FRAME  SYNC 

FRAME 

DATA 

DATA 

PATTERN 

MICRO  TIME 

WORD  4 

WORD  8 

24  TK  bit  times 


FRAME  SYNC 

DATA 

DATA 

DATA 

PATTERN 

WORD  1 

WORD  5 

WORD  9 

24  TK  bit  times 


Figure  8-2.  Multiple  Tape  Track  Spread  Format  (4-Track  Spread  Example) 


•  TK2.  The  PCM  stream  designated  TK2  shall  be  constructed  as  the  frame 
synchronization  word,  followed  by  the  low  order  frame  time  word,  followed  by 
data  words. 

•  TK3.  The  PCM  stream  designated  TK3  shall  be  constructed  as  the  frame 
synchronization  word,  followed  by  the  microsecond  frame  time  word,  followed 
by  data  words. 

•  TK4.  The  PCM  stream  designated  TK4  shall  be  constructed  as  the  frame 
synchronization  word,  followed  by  the  first  data  word,  followed  by  other  data 
words. 


NOTE^ 

Schemes  using  one,  two,  or  three  tracks  for  a  given  bus  shall 

follow  like  construction;  that  is,  sequencing  through  the  data 

a 

track  by  track.  If  frame  time  is  not  used,  data  words  shall 

immediately  follow  the  frame  synchronization  patterns. 

NOTE 


5^ 


Additional  care  must  be  exercised  in  data  processing  and  reduction 
if  the  last  word  in  the  final  track  spread  stream  is  a  MIL-STD-1553 
command  word.  The  associated  message  time  tag  will  not  appear 
until  after  the  synchronization  and  time  words  in  the  next  frame. 


8.6  MIL-STD-1553 

The  following  subsections  describe  specific  formatting  requirements  for  the  100  percent 
acquisition  of  MIL-STD-1553  bus  information. 
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8.6.1  Definitions 

a.  Bus  Monitor.  The  terminal  assigned  the  task  of  reeeiving  bus  traffie  and  extraeting  all 
information  to  be  used  at  a  later  time. 

b.  Data  Bus.  All  hardware  ineluding  twisted  shielded  pair  eables,  isolation  resistors,  and 
transformers  required  to  provide  a  single  data  path  between  the  bus  eontroller  and  all 
assoeiated  remote  terminals. 

e.  Dual  Redundant  Data  Bus.  The  use  of  two  data  buses  to  provide  multiple  paths  between 
the  subsystems. 

d.  Bus  Loading.  The  pereentage  of  time  the  data  bus  is  aetive. 

e.  Maximum  Burst  Length.  The  maximum  length  of  a  eontinuous  burst  of  messages  with 
minimum  length  message  gaps. 

f.  Bus  Error.  A  eondition  that  violates  the  definition  of  MIL-STD-1553  word  strueture. 
Conditions  sueh  as  synehronization,  Manehester,  parity,  non-eontiguous  data  word,  and 
bit  eount/word  errors  are  all  eonsidered  word  type  errors.  System  protoeol  errors  sueh  as 
ineorreet  word  eount/message  and  illegal  mode  eodes  are  not  eonsidered  bus  errors. 

8.6.2  Souree  Signal 

The  souree  of  data  is  a  signal  eonforming  to  MIL-STD-1553.  Format  provisions  are 
made  for  a  dual  redundant  data  bus  system.  The  interfaee  deviee  performing  the  data  aequisition 
shall  be  eonfigured  as  a  bus  monitor.  Figure  8-3  depiets  in  bloek  diagram  form  the  eoneept  of 
100  pereent  MIF-STD-1553  bus  data  aequisition. 


Figure  8-3.  System  Bloek  Diagram 
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NOTE 


In  the  design  of  the  interface  to  the  MIL-STD-1553  bus,  it  may  be  necessary 
to  include  buffers  to  prevent  loss  of  data  and  to  conserve  bandwidth.  The 
buffer  size  is  influenced  by  bus  loading,  maximum  burst  length,  output  bit 
rate,  tape  recording  speed,  time  tagging,  and  auxiliary  inputs. 


8.6.3  Word  Structure 

The  specific  word  structure  provisions  to  be  used  for  MIL-STD-1553  bus  formatted 
output  are  described  below. 

a.  The  formatted  data  shall  be  a  24-bit  word  constructed  as  shown  in  Table  8-1  and  Table 

M- 

b.  The  information  extracted  from  the  MIL-STD-1553  bus  shall  have  the  synchronization 
pattern  and  parity  bit  removed. 

c.  Each  incoming  MIL-STD-1553  word  (Command,  Status,  or  Data),  auxiliary  input,  or 
time  word  shall  be  appropriately  labeled  with  a  4-bit  Content  Identification  Label  as 
described  in  Table  8-1  and  Table  8-2. 

d.  Data  extracted  from  the  MIL-STD-1553  bus  shall  maintain  bit  order  integrity  in  the 
information  field  for  a  command,  status,  data,  and  error  word.  Bit  position  4  in  the  MIL- 
STD-1553  bus  word  shall  be  placed  into  bit  position  9  in  the  formatted  data  word.  The 
remaining  bits  of  the  MIL-STD-1553  bus  word  shall  be  placed  in  successive  bit  positions 
in  the  formatted  data  word.  Transposing  or  reordering  of  the  bits  is  not  permitted. 

e.  For  bus  errors  as  defined  in  item  f  of  Subsection  8.6.1  (Error  A  -  1 100  or  Error  B  -  1000), 
the  synchronization  pattern  and  the  parity  bit  are  removed  as  stated  in  item  b  above.  The 
Information  Content  bits,  9  -  24,  of  the  formatted  word  shall  contain  the  resulting  16-bit 
pattern  extracted  from  the  bus. 


Table  8-2.  MIL-STD-1553  Formatted  Word  Construction 

BIT  POSITION 

1 

2  3  4 

5  6  7  8 

9  10  11  12  .  .  .  21  22  23  24 

P 

A 

R 

I 

T 

Y 

Bl 

a.  Fi( 

BUS 

IDENT 

EABEE 

OR 

JS  IDENT 
iBEE 

jld  Definition 

CONTENT 

IDENT 

EABEE 

INFORMATION 

CONTENT 
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BIT 

BIT 

1 

2  3  4 

I  2 

3 

4 

0 

0  0  0 

BUS  I 

I  0 

0 

0 

BUS  9 

0 

0  0  I 

BUS  2 

I  0 

0 

I 

BUS  10 

0 

0  1  0 

BUS  3 

I  0 

I 

0 

BUS  II 

0 

0  I  I 

BUS  4 

I  0 

I 

I 

BUS  12 

0 

I  0  0 

BUS  5 

I  I 

0 

0 

BUS  13 

0 

I  0  I 

BUS  6 

I  I 

0 

I 

BUS  14 

0 

I  I  0 

BUS  7 

I  I 

I 

0 

BUS  15 

0 

I  I  I 

BUS  8 

I  I 

I 

I 

BUS  16 

b.  MIL-STD-1553  Bus/Group  Identification  Label  Definition;  Bits  (1)  2,  3,  &  4 


BIT 

BIT 

5 

6 

7 

8 

5 

6 

7 

8 

1 

1 

I 

I 

COMMAND  A 

0 

I 

I 

I 

TIME  -  HIGH  ORDER 

1 

1 

1 

0 

STATUS  A 

0 

I 

I 

0 

TIME  -  LOW  ORDER 

1 

1 

0 

I 

DATA  A 

0 

I 

0 

I 

TIME  -  MICROSECOND 

1 

1 

0 

0 

ERROR  A 

0 

I 

0 

0 

TIME  -  RESPONSE 

1 

0 

I 

I 

COMMAND  B 

0 

0 

I 

I 

USER  DEEINED 

I 

0 

I 

0 

STATUS  B 

0 

0 

I 

0 

USER  DEEINED 

1 

0 

0 

I 

DATAB 

0 

0 

0 

I 

EILL  WORD 

1 

0 

0 

0 

ERROR  B 

0 

0 

0 

0 

BUEEER  OVERELOW 

NOTE: 

A  =  primary  channel  of  the  dual  redundant  bus;  B  =  seeondary  ehannel 
c.  MIL-STD-1553  Content  Identifieation  Label  Definition;  Bits  5,  6,  7,  &  8 


8.6.4  Time  Words 
8.6.4. 1  Time  Tagging 

If  time  tagging  of  the  oecurrenee  of  MIL-STD-1553  messages  is  neeessary  to  satisfy  user 
requirements,  the  first  command  word  of  the  message  shall  be  time  tagged.  The  time  words  shall 
immediately  follow  the  first  command  word  in  the  following  order:  high  order  time,  low  order 
time,  and  microsecond  time. 


8. 6.4. 2  Response  Time  Word 

The  optional  response  time  word  shall  have  one-microseeond  resolution  and  shall 
indicate  the  response  time  of  the  data  bus.  The  response  time  word  shall  immediately  preeede 
the  status  word  associated  with  it. 


NOTE 


If  the  response  time  function  is  not  used. 
Content  Identification  Label  0100  may  be 
assigned  to  user-defined  inputs. 


8.7  ARINC  429 

The  following  subsections  describe  specific  formatting  requirements  for  the  100  percent 
acquisition  of  ARINC  429  channel  information. 
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8.7.1  Definitions 

a.  Monitor.  The  reeeiver  or  sink  assigned  the  task  of  reeeiving  bus  traffie  and  extraeting  all 
information  to  be  used  at  a  later  time. 

b.  Data  Bus.  All  hardware  ineluding  twisted  shielded  pair  eables,  required  to  provide  a 
single  data  path  between  the  transmitter  or  souree  and  the  assoeiated  reeeivers  or  sinks. 

e.  Channel  Error.  Conditions  deteeted  whieh  violate  the  definition  of  ARINC  429  word 
strueture  as  speeified  in  ARINC  speeifieation  429P1,  429P2,  and  429P3.  Conditions 
sueh  as  parity  and  bit  eount/word  errors  are  all  eonsidered  among  word  type  errors. 
System  protoeol  errors  are  not  eonsidered  bus  errors. 

8.7.2  Souree  Signal 

The  souree  of  data  is  a  signal  eonforming  to  ARINC  429.  Format  provisions  are  made 
for  up  to  64  ehannels.  The  interfaee  deviee  performing  the  data  aequisition  shall  be  eonfigured 
as  a  monitor.  In  prineiple,  Figure  8-3  depiets  in  bloek  diagram  form  the  eoneept  of  100  pereent 
bus  data  aequisition. 

8.7.3  Word  Strueture 

The  following  deseriptions  eontain  speeifie  word  strueture  provisions  to  be  used  for  the 
ARINC  429  formatted  output. 

a.  The  formatted  data  shall  be  a  24-bit  word  eonstrueted  as  shown  in  Table  8-1  and  Table 

M- 

b.  Eaeh  ineoming  ARINC  429  word,  auxiliary  input,  or  time  word  shall  be  appropriately 
labeled  with  a  4-bit  Content  Identifieation  Fabel  as  deseribed  in  Table  8-1  and  Table  8-3. 

e.  The  format  provides  for  addressing  of  up  to  64  ehannels.  Eaeh  Bus/Group  Identifieation 
Fabel  (designated  GROUP  X)  may  be  assoeiated  with  up  to  4  independent  ARINC  429 
ehannels  through  the  use  of  a  High  and  Fow  Syllable  teehnique  deseribed  in  item  d  below 
and  shown  in  Table  8-4. 

d.  Data  extraeted  from  the  ARINC  429  ehannel  shall  maintain  bit  order  integrity  in  the 
Information  Content  field.  Eaeh  ARINC  429  word  is  32  bits  in  length.  To  aeeommodate 
this  word  length  within  the  deseribed  format,  eaeh  ARINC  word  is  divided  into  two 
segments,  eaeh  16  bits  in  length.  These  segments  will  be  referred  to  as  ARINC  High 
Syllable  and  ARINC  Fow  Syllable.  Table  8-4  deseribes  the  mapping  of  the  32-bit 
ARINC  429  word  into  the  Information  Content  bits  (9  -  24)  of  the  ARINC  High  and  Fow 
Syllable  words.  Transposing  or  reordering  of  the  bits  is  not  permitted. 

e.  For  ehannel  errors  defined  in  item  c  of  Subseetion  8.7.1,  the  following  proeedure  shall  be 
followed.  An  error  word  shall  be  generated  using  the  appropriate  bus/group 
identifieation  label  and  0100  as  the  eontent  identifieation  label.  Bits  9-12  shall  eontain 
the  eontent  identifieation  label  eode  assoeiated  with  the  appropriate  ARINC  high  syllable 
ehannel,  bits  13-16  shall  eontain  the  eontent  identifieation  label  for  the  ARINC  low 
syllable  assoeiated  with  that  ehannel,  and  bits  17  -  24  are  available  for  system  level 
diagnosties  and  are  not  speeified  here.  The  next  oeeurrenee  of  that  bus/group 
identifieation  label  eoupled  with  those  ARINC  high  and  low  syllable  eontent 
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identification  labels  shall  contain  the  respective  data  extracted  from  the  channel  that  was 
deemed  to  be  in  error.  The  information  content  bits,  9  -  24,  of  the  formatted  word  shall 
contain  the  resulting  16-bit  pattern  syllables  as  extracted  from  the  channel. 

Table  8-3.  ARINC  429  Formatted  Word  Construction 


BIT  POSITION 


a.  Field  Definition 


BIT 

BIT 

1 

2  3 

4 

12  3  4 

0 

0  0 

0 

GROUP  I 

10  0  0 

GROUP  9 

0 

0  0 

I 

GROUP  2 

10  0  1 

GROUP  10 

0 

0  I 

0 

GROUP  3 

10  10 

GROUP  II 

0 

0  I 

I 

GROUP  4 

I  0  I  I 

GROUP  12 

0 

I  0 

0 

GROUP  5 

110  0 

GROUP  13 

0 

I  0 

I 

GROUP  6 

I  I  0  I 

GROUP  14 

0 

I  I 

0 

GROUP  7 

I  I  I  0 

GROUP  15 

0 

I  I 

I 

GROUP  8 

I  I  I  I 

GROUP  16 

b.  ARINC  429  Bus/Group  Identification  Label  Definition;  Bits  (1)2,  3,  &  4 


BIT 

BIT 

5 

6 

7 

8 

5 

6 

7 

8 

I 

I 

I 

I 

High  Syllable  #4 

0 

I 

I 

I 

TIME  -  HIGH  ORDER 

I 

I 

I 

0 

Low  Syllable  #4 

0 

I 

I 

0 

TIME  -  EOW  ORDER 

I 

I 

0 

I 

High  Syllable  #3 

0 

I 

0 

I 

TIME  -  MICROSECOND 

I 

I 

0 

0 

Low  Syllable  #3 

0 

I 

0 

0 

ERROR 

I 

0 

I 

I 

High  Syllable  #2 

0 

0 

I 

I 

USER  DEEINED 

I 

0 

I 

0 

Low  Syllable  #2 

0 

0 

I 

0 

USER  DEEINED 

I 

0 

0 

I 

High  Syllable  #1 

0 

0 

0 

I 

EIEE  WORD 

I 

0 

0 

0 

Low  Syllable  #1 

0 

0 

0 

0 

BUEEER  OVEREEOW 

c.  ARINC  429  Content  Identification  Label  Definition;  Bits  5,  6,  7,  &  8 
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Table  8-4. 

ARINC  Bit  to  Formatted  Word  Bit  Mapping 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

a.  Information  Content  field  bits 

32 

31 

30 

29 

28 

27 

26 

25 

24 

23 

22 

21 

20 

19 

18 

17 

b.  ARINC  High  Syllable  bit  mapping 

16 

15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

c.  ARINC  Low  Syllable  bit  mapping 

8.7.4  Time  Words 

If  time  tagging  of  the  occurrence  of  ARINC  429  messages  is  necessary  to  satisfy  user 
requirements,  the  time  words  shall  immediately  follow  the  ARINC  Low  Syllable  word  in  the 
following  order: 

a.  High-order  time; 

b.  Low-order  time; 

c.  Microsecond  time. 


END  OF  CHAPTER  8 
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CHAPTER  9 

Telemetry  Attributes  Transfer  Standard 


9.1  General 

Telemetry  attributes  are  those  parameters  required  by  the  receiving/processing  system  to 
acquire,  process,  and  display  the  telemetry  data  received  from  the  test  item/source.  The 
telemetry  attributes  defined  in  this  chapter  provide  the  information  required  to  set  up  the 
telemetry  receiving  and  processing  equipment.  The  format,  while  not  necessarily  compatible 
with  any  receiving/processing  system,  will  allow  test  ranges  or  other  receiving  systems  to 
develop  a  computer  conversion  program  to  extract  the  information  and  to  set  up  data  required  for 
their  unique  equipment  configuration. 

The  intent  of  this  chapter  is  to  cover,  primarily,  attributes  and  terminology  included  in  or 
consistent  with  the  other  chapters  within  this  telemetry  standards  document.  For  example,  pulse 
code  modulation  (PCM)  format  attributes  should  comply  with  the  PCM  standards  as  given  in 
Chapter  4.  Other  attributes  are  sometimes  included  for  service  and  utility,  but  should  not  be 
construed  as  endorsements  apart  from  the  other  chapters. 

9.2  Scope 

The  Telemetry  Attributes  Transfer  Standard  (TMATS)  provides  the  definition  of  the 
telemetry  attributes  and  specifies  the  media  and  data  format  necessary  to  permit  the  transfer  of 
the  information  required  to  set  up  the  telemetry  receiving/processing  functions  at  a  test  range. 
The  standard  does  not  conform  to,  nor  does  it  define,  existing  or  planned  capabilities  of  any 
given  test  range.  The  parameters  included  in  this  document  are  defined  by  specific  reference. 
Other  nonstandard  parameter  values/  definitions  may  be  included  in  the  comments  section  of 
each  group. 

9.3  Purpose 

The  TMATS  provides  a  common  format  for  the  transfer  of  information  between  the  user 
and  a  test  range  or  between  ranges  (see  Appendix  9- A).  This  format  will  minimize  the  “station- 
unique”  activities  that  are  necessary  to  support  any  test  item.  In  addition,  TMATS  is  intended  to 
relieve  the  labor-intensive  process  required  to  reformat  the  information  by  providing  the 
information  on  computer-compatible  media,  thereby  reducing  errors  and  requiring  less 
preparation  time  for  test  support. 

9.4  Media  and  Data  Structure 

A  variety  of  physical  and  electronic  media  is  available  for  use  in  exchanging  attribute 
information.  The  most  important  factor  in  selecting  a  medium  is  that  the  parties  involved  agree 
to  use  that  specific  medium.  If  any  data  compression  (such  as  backup/restore  or  zip/unzip)  will 
be  used,  both  parties  should  agree  to  its  use. 

A  cover  sheet  describing  the  system  that  produced  the  attribute  medium  should 
accompany  the  attribute  information.  A  recommended  format  for  the  cover  sheet  is  given  in 
Appendix  9-B. 
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9.4.1  Physical  Format 

Attributes  for  each  mission  configuration  are  to  be  supplied  in  a  single  physical  file  with 
contents  as  7-bit  American  Standard  Code  for  Information  Interchange  (ASCII)  coded 
characters.  Line  feed  (LF)  and  carriage  return  (CR)  may  be  used  to  improve  readability  of  the 
information.  Nonprintable  characters  will  be  discarded  by  the  destination  agency  prior  to 
translating  the  attributes  into  telemetry  system  configuration  information. 

Multiple  mission  configurations  may  be  provided  on  a  single  disk;  however,  each 
configuration  must  be  in  a  separate  file  identified  in  the  disk  directory.  File  names  should  use 
the  file  extensions  “.TXT”  to  indicate  a  text  file  or  “.TMT”  or  “.TMA”  to  indicate  a  TMATS  file. 
A  stick-on  label  and  the  accompanying  cover  sheet  identify  the  file  names  corresponding  to  the 
mission  configuration  used  for  each  mission. 


9.4.2  Logical  Format 

Each  attribute  appears  in  the  file  as  a  unique  code  name  and  as  a  data  item.  The  code 
name  appears  first,  delimited  by  a  colon.  The  data  item  follows,  delimited  by  a  semicolon. 

Thus,  an  attribute  is  formatted  as  A:B;  -  where  A  is  the  code  name  and  B  is  the  data  item,  in 
accordance  with  (lAW)  the  tables  in  Section  9A.  Numeric  values  for  data  items  may  be  either 
integer  or  decimal.  Scientific  notation  (see  note  below)  is  allowed  only  for  the  specific  data 
items  defined  for  its  use  in  the  tables  in  Section  9^.  For  alphanumeric  data  items,  including 
keywords,  either  upper  or  lower  case  is  allowed;  TMATS  is  not  case  sensitive.  All  defined 
keyword  values  are  shown  as  upper  case  and  enclosed  in  quotes  in  the  tables  in  Section  9.5. 
Leading,  trailing,  and  embedded  blanks  are  assumed  to  be  intentional;  they  can  be  ignored  in 
most  cases  but  should  not  be  used  in  code  names,  keywords,  and  data  items  used  as  links,  such  as 
measurement  name.  Semicolons  are  not  allowed  in  any  data  item  (including  comment  items). 
Any  number  of  attributes  may  be  supplied  within  a  physical  record.  Attributes  may  appear  in 
any  order. 


Any  numeric  data  item  expressed  in  scientific  notation  must  conform  to  the 
following  regular  expression: 

([-+]?(([0-9]-t\.?[0-9]*)l([0-9]n.[0-9]-t)))([eE][-t]?[0-9]{l,3}) 

This  expression  limits  the  number  of  digits  in  the  exponent  to  three  or  less, 
but  allows  any  number  of  digits  (including  none)  both  before  and  after  the 
decimal  point  in  the  fraction.  Also,  the  decimal  point  can  be  omitted  (for 
example,  “3E5”  is  valid). 


The  two  basic  types  of  attribute  code  names  are  single-entry  and  multiple-entry.  Single¬ 
entry  attributes  are  those  for  which  there  is  only  one  data  item.  Multiple-entry  attributes  appear 
once  in  the  definition  tables  in  Section  9A  but  have  multiple  items;  these  items  are  assigned  a 
number.  The  number  appears  in  the  code  name  preceded  by  a  hyphen.  Eor  example,  data  source 
identifiers  might  have  the  following  entries: 

G\DSI- 1 :  Aircraft; 

G\DSI-2:Missile; 

G\DSI-3:Target; 
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The  code  name  COMMENT  may  be  used  to  interject  comments  to  improve  readability. 
The  comment  data  items,  such  as  G\COM,  are  intended  to  convey  further  details  within  the 
TMATS  file  itself.  Comments  must  follow  the  attribute  logical  format,  as  shown  below: 

COMMENT:  This  is  an  example  of  a  comment; 


Refer  to  Section  9^  for  detailed  definitions  of  code  names  and  attributes  and  Appendix 
9-C  for  an  example  application  of  this  standard. 


NOTE^ 

It  is  recommended  that  data  source/link  names  and  measurement  names 

/P 

consist  of  only  the  following: 

a 

•  Capitalized  alphabetic  characters 

•  Numeric  characters 

•  The  underscore  symbol 

Specifically,  it  is  recommended  to  avoid  the  use  of  embedded  spaces  and 

other  special  characters  in  data  source/link  names  and  measurement  names. 

9.4.3  Extensible  Markup  Eanguage  Eormat 

In  addition  to  the  code  name  format  described  in  Subsection  9.4.2,  TMATS  attributes  can 
also  be  expressed  in  extensible  markup  language  (XME).  The  TMATS  XME  format  is 
implemented  as  a  standard  XME  schema  consisting  of  a  collection  of  XME  schema  document 
(XSD)  files,  which  can  be  found  here.  Additionally,  a  graphical  depiction  of  the  schema  in 
HTME  format  is  available  here.  The  HTME  files  are  very  large  and  will  take  time  to  download. 

The  TMATS  XME  schema  is  identical  in  content  to  the  telemetry  attributes  described  in 
Section  9^  below,  with  the  exceptions  shown  in  the  following  list. 

a.  There  is  a  C  group  for  each  data  link  instead  of  only  one  C  group  in  the  TMATS  file. 

b.  The  schema  has  no  counter  (“\N”)  attributes;  they  are  not  needed  in  XME. 

c.  Keyword  attribute  values  are  expanded  for  readability  in  the  schema. 

d.  Date  and  time  formats  are  different;  the  schema  uses  the  XME  standard  date  and  time 
formats  (not  the  ones  in  Section  9.5). 

e.  Text  entries  in  the  XME  schema  may  contain  semicolons;  the  code  name  format  uses  the 
semicolon  as  a  delimiter. 

f.  The  inherent  structure  of  an  XME  schema  implies  order,  while  the  code  name  format 
allows  the  attributes  to  be  given  in  any  order. 


In  addition  to  the  TMATS  XME  schema,  there  are  two  other  XME  schemas  that  describe 
related  areas  of  information.  The  first  one.  Data  Display  Markup  Eanguage  (DDME),  covers 
commonly  used  types  of  data  displays.  Refer  to  Section  9^  for  a  full  description  of  this  standard 
format  for  data  display  definitions.  The  other  one.  Instrumentation  Hardware  Abstraction 
Eanguage  (IHAE),  deals  with  the  instrumentation  hardware  configuration  on  a  test  item.  See 
Section  9n_  for  a  full  description  of  this  standard  format  for  describing  instrumentation  hardware. 
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9.5  Telemetry  Attributes 


The  description  of  the  mission  configuration  includes  all  potential  sources  of  data;  these 
sources  are  radio  frequency  (RF)  links,  pre-  or  post-detected  tapes,  and  onboard  recorded  tapes 
and  storage  media.  Each  of  these  data  sources  has  unique  characteristics  that  must  be  defined. 
Each  source  is  given  a  unique  identity  and  its  characteristics  are  specifically  defined  in 
associated  attribute  fields.  In  multiplexed  systems,  each  data  stream  is  uniquely  identified  by  a 
data  link  name,  which  is  related  to  the  data  source  name. 


NOTE 


y 


Only  the  information  that  is  essential  to  define  the  attributes  of  a  system 
is  required.  Non-applicable  information  does  not  need  to  be  included  in 
the  file;  however,  all  attribute  information  given  is  to  be  provided  in  the 
specified  format. 


The  attributes  defined  in  this  section  proceed  from  the  general  level  to  the  detailed  level. 
The  groups,  defined  in  terms  of  data  to  be  entered,  are: 

a.  General  Information:  Establishes  the  top-level  program  definition  and  identifies  the  data 
sources. 

b.  Transmission  Attributes:  Defines  an  RE  link.  There  will  be  one  group  for  each  RE  link 
identified  in  the  General  Information  group. 

c.  Recorder-Reproducer  Attributes:  Identifies  a  tape  or  storage  data  source. 

d.  Multiplex/Modulation  Attributes:  Describes  the  EM/EM  (frequency  modulation), 

EM/PM  (phase  modulation),  or  PM/PM  multiplex  characteristics.  Each  multiplexed 
waveform  must  have  a  unique  set  of  attributes.  Eor  the  analog  measurement,  the  tie  to 
the  engineering  units  conversion  is  made  in  this  group. 

e.  Digital  Data  Attributes:  Divided  into  four  groups:  the  PCM  Eormat  Attributes,  the  PCM 
Measurement  Description,  the  Bus  Data  Attributes,  and  the  Message  Data  Attributes. 

(1)  PCM  Eormat  Attributes:  Defines  the  PCM  data  format  characteristics,  including 
embedded  formats.  Each  PCM  format  will  have  a  separate  format  attributes  group. 

(2)  PCM  Measurement  Descriptions:  Defines  each  PCM  measurement  within  the 
overall  PCM  format. 

(3)  Bus  Data  Attributes:  Specifies  the  PCM-encoded  Military  Standard  (MIE-STD) 
1553  or  Aeronautical  Radio,  Incorporated  (ARINC)  429  bus  format  characteristics 
or  the  direct  recorder  track/channel  MIE-STD- 1553  or  ARINC  429  bus  format 
characteristics. 

(4)  Message  Data  Attributes:  Specifies  the  message-based  data  streams. 

f.  Pulse  Amplitude  Modulation  Attributes:  As  of  RCC  IRIG  106-13,  this  section  has  been 
removed.  See  Annex  A.l  for  applicable  Pulse  Amplitude  Modulation  data  standards. 

g.  Data  Conversion  Attributes:  Contains  the  data  conversion  information  for  all 
measurements  in  this  telemetry  system.  The  calibration  data  and  conversion  definition  of 
raw  telemetry  data  to  engineering  units  is  included.  The  tie  to  the  measurands  of  the 
telemetry  systems  defined  in  the  previous  groups  is  via  the  measurement  name. 
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h.  Airborne  Hardware  Attributes:  Defines  the  configuration  of  airborne  instrumentation 
hardware  in  use  on  the  test  item. 

i.  Vendor-Specific  Attributes:  Provides  information  that  is  specific  to  a  vendor. 

9.5.1  Contents 

The  following  subparagraphs  discuss  the  organization  of  the  attributes  and  their 
relationships  with  the  various  groups. 

a.  Organization.  Attribute  information  is  organized  according  to  a  hierarchical  structure  in 
which  related  items  are  grouped  and  given  a  common  heading.  The  number  of  levels 
varies  within  the  overall  structure  and  is  a  function  of  the  logical  association  of  the 
attributes.  At  the  highest  level,  the  telemetry  attributes  are  defined  for  the  groups 
displayed  in  Table  9-1. 


Table  9-1.  Telemetry  Attribute  Groups 

Identifier 

Title 

G 

General  Information 

T 

Transmission  Attributes 

R 

Recorder-Reproducer  Attributes 

M 

Multiplex/Modulation  Attributes 

P 

PCM  Format  Attributes 

D 

PCM  Measurement  Description 

B 

Bus  Data  Attributes 

S 

Message  Data  Attributes 

C 

Data  Conversion  Attributes 

H 

Airborne  Hardware  Attributes 

V 

Vendor-Specific  Attributes 

X 

TMATS  extension  Attributes 

Within  the  structure,  a  lower-case  letter,  for  example,  n,  p,  or  r,  indicates  a  multiple-entry 
item  with  the  index  being  the  lower-case  letter.  The  range  of  these  counters  is  from  one 
to  the  number  indicated  in  another  data  entry,  usually  with  the  appendage  \N,  and  have  no 
missing  values. 

The  Usage  Attributes  column  within  each  table  describes  how  a  particular  attribute  is  to 
be  used,  when  it  is  allowed,  etc.  If  there  are  enumerations  for  the  attribute,  the 
enumeration  values  and  their  descriptions  will  appear  in  this  column.  There  are  7 
possible  fields  within  this  column  for  each  attribute. 

•  R/R  Ch  10  Status:  This  describes  special  rules  for  creating  TMATS  files  to  support 
setup  of  a  Chapter  10  recorder.  A  value  of  “R”  requires  that  the  attribute  be  specified 
in  the  TMATS  file  whenever  the  attribute  is  allowed.  A  value  of  “RO”  indicates  that 
when  an  applicable  data  type  or  group  is  used,  the  attribute  must  be  specified  in  the 
TMATS  file.  A  value  of  “RO-PAK”  indicates  the  attribute  must  be  specified  when 
the  Data  Packing  Option  (R-x\PDP-n)  is  either  UNPACKED  (UN)  or  PACKED 
(PFS).  If  the  attribute  is  specified  in  the  TMATS  file,  it  must  contain  valid 
information. 
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•  Allowed  when:  This  describes  when  an  attribute  is  allowed  to  be  specified  inside  of  a 
TMATS  file. 

•  Required  when:  This  describes  when  an  attribute  must  be  specified  inside  of  a 
TMATS  file.  If  the  Required  condition  is  “When  Allowed”,  then  it  must  be  specified 
when  the  “Allowed  when”  condition  is  met. 

•  Links  to:  Specifies  a  list  of  attributes  that  the  attribute  links  to  by  value. 

•  Links  from:  Specifies  a  list  of  attributes  that  link  to  this  attribute  by  value.  Any 
attribute  with  a  Links  from:  is  a  key  and  must  be  unique  in  the  TMATS  file. 

•  Range:  This  describes  the  values  or  ranges  that  may  be  specified.  A  range  might  be 
specified  with  exact  values  or  may  reference  the  value  of  another  TMATS  attribute. 
The  range  may  also  be  simply  a  number  of  characters  that  represents  the 
recommended  maximum  length  of  the  value.  Where  possible,  the  valid  ranges  for 
numbers  are  specified,  however  each  range  should  be  consulted  as  to  their  specific 
capabilities  There  are  several  special  values  for  Range: 

o  Enumeration:  This  specifies  that  the  value  must  be  one  of  the  values  listed  in 
the  description  column  of  the  attribute.  The  enumerations  will  follow. 

o  Floating  Point:  This  specifies  a  legal  floating  point,  integer,  or  scientific 
notation  value. 

o  xxx.xxx.xxx.xxx:  This  specifies  an  Internet  Protocol  (IP)  address  where  each 
“xxx”  is  a  value  from  0-255. 

o  Hexadecimal:  A  numeric  value  base  16  containing  0-9  and  A-F  or  a-f. 

o  Binary:  A  numeric  value  base  2  containing  0-1 

o  Binary  pattern:  A  binary  numeric  pattern  consisting  of  0,  1,  or  “X”  for  don’t 
care. 

o  “X”:  the  character  “X” 

o  MM-DD-YYYY-HH-MI-SS:  This  specifies  a  date  and  time.  MM  is  the 
month  from  01  to  12.  DD  is  the  day  of  the  month  from  01  to  31.  YYYY  is 
the  4  digit  year.  HH  is  the  hour  of  the  day  from  00  to  23.  MI  is  the  minute  of 
the  hour  from  00  to  59.  SS  is  the  second  from  00  to  59. 


•  Default:  This  identifies  the  default  value  required  to  process  a  TMATS  file  when  the 
file  itself  does  not  contain  the  attribute. 


NOTE 


T 


In  previous  versions  of  this  document,  there  existed  code  name  tags  *R- 
CHIO*,  *RO-CH10*  and  *RO-CH10-PAK*.  These  have  been  removed  in 
favor  of  the  above  attribute  column.  If  the  R/R  ChlO  Status  field  is  “R”,  then 
the  attribute  must  be  included  in  the  TMATS  file  if  all  other  conditions  apply 
even  if  it  has  a  default. 


b.  Group  Relationships.  Representative  interrelationships  between  the  various  groups  are 
shown  pictorially  in  Figure  9-1.  Not  all  valid  paths  are  shown.  All  valid  paths  are 
documented  in  “Finks  to:”  and  “Finks  from:”  attributes. 
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NOT^^ 

a. 

Data  Source  ID  is  unique  within  a  General  Information  group  (G).  It 
ties  the  Transmission  group  (T)  or  the  Recorder-Reproducer  group  (R) 
or  both  to  the  G  group  and  to  the  Multiplex/Modulation  group  (M). 

b. 

The  tie  from  the  M  group  to  a  PCM  group  (P)  is  the  Data  Link  Name. 

c. 

The  tie  from  the  P  group  to  an  embedded  P  group  is  another  Data  Link 
Name. 

d. 

The  tie  from  the  M  group  to  the  Data  Conversion  group  (C)  for  an 
analog  measurement  is  the  Measurement  Name. 

e. 

The  tie  from  the  P  group  to  the  PCM  Measurement  Description  group 
(D)  or  Bus  group  (B)  is  the  Data  Link  Name. 

f. 

The  tie  from  the  R  group  to  the  P  group  is  from  the  Channel  Data 

Link  Name  (R)  to  the  Data  Link  Name  (P). 

g- 

The  tie  from  the  R  group  to  the  B  group  is  from  the  Channel  Data 

Link  Name  or  Sub-Channel  Name  (R)  to  the  Data  Link  Name  (B). 

h. 

The  tie  from  the  R  group  to  the  Message  Data  group  (S)  is  from  the 
Channel  Data  Link  Name,  Sub-Channel  Name,  or  Network  Name  (R) 
to  the  Data  Link  Name  (S). 

i. 

The  tie  from  either  the  R,  D,  B,  or  S  group  to  the  Data  Conversion 
group  is  the  Measurement  Name. 
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(FM) 


Figure  9-1.  Group  Relationships 
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9.5.2  General  Information  (G) 

The  General  Information  group  provides  overall  program  information.  Figure  9-2  below 
gives  the  overall  information  that  is  included  in  this  group.  Table  9-2  identifies  and  defines  the 
data  required,  including  the  dates  associated  with  the  detailed  information.  Since  the 
identification  of  the  data  sources  is  an  integral  part  of  the  remaining  groups,  each  source  must  be 
uniquely  identified. 


Figure  9-2.  General  Information  Group  (G) 

Code  Name 

PROGRAM  NAME  -  9-10 

(G\PN) 

9-10 

TEST  ITEM 

(G\TA) 

^Information 

TMATS  EIEE  NAME 

(G\PN) 

RCC  IRIG  106  REVISION  EEVEE 

(G\I06) 

ORIGINATION  DATE 

(G\OD) 

REVISION  NUMBER 

(G\RN) 

REVISION  DATE 

(G\RD) 

UPDATE  NUMBER 

(G\UN) 

UPDATE  DATE 

(G\UD) 

TEST  NUMBER 

(G\TN) 

NUMBER  OE  POINTS  OP  CONTACT 

(G\POC\N) 

9-11 

*Point  of  Contact 

NAME 

(G\POCI-n) 

AGENCY 

(G\POC2-n) 

ADDRESS 

(G\POC3-n) 

TEEEPHONE 

(G\POC4-n) 

9-11 

*Data  Source  Identification 

NUMBER  OP  DATA  SOURCES 

(G\DSEN) 

DATA  SOURCE  ID 

(G\DSI-n) 

DATA  SOURCE  TYPE 

(G\DST-n) 

DATA  SOURCE  SECURITY  CEASSIPICATION 

(G\DSC-n) 

9-12 

*Test 

nformation 

TEST  DURATION 

(G\TII) 

PRE-TEST  REQUIREMENT 

(G\TI2) 

POST-TEST  REQUIREMENT 

(G\TI3) 

SECURITY  CEASSIPICATION 

(G\SC) 

9-13 

*TMATS  Checksum 

MESSAGE  DIGEST/CHECKSUM 

(G\SHA) 

9-13 

*  Comments 

COMMENTS 

(G\COM) 

*Heading  Only  -  No  Data  Entry 
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Table  9-2.  General  Information  Group  (G) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

PROGRAM  NAME 

G\PN 

Allowed  when:  Always 

Name  of  program. 

Range:  16  characters 

TEST  ITEM 

G\TA 

Allowed  when:  Always 

Test  item  description  in  terms  of  name,  model, 
platform,  or  identification  code,  as  appropriate. 

Range:  64  characters 

Information 

TMATS  EIEE 

NAME 

G\PN 

Allowed  when:  Always 

Name  of  this  TMATS  file. 

Range:  256  characters 

RCC  IRIG  106 
REVISION  EEVEE 

G\106 

R/R  Ch  10  Status:  R 

Version  of  RCC  IRIG  106  standard  used  to  generate 
this  TMATS  file.  The  last  2  digits  of  the  year  should 
be  used.  Use  a  leading  0  if  necessary. 

Allowed  when:  Always 

Required  when:  Always 

Range:  0-99 

ORIGINATION 

DATE 

G\OD 

Allowed  when:  Always 

Date  of  origination  of  this  mission  configuration. 
“DD”(Day).  “MM”  (Month).  “YYYY”  (Year). 

Range:  MM-DD-YYYY 

REVISION 

NUMBER 

G\RN 

Allowed  when:  Always 

Revision  number  associated  with  this  mission 
configuration. 

Range:  0-9999 

REVISION  DATE 

G\RD 

Allowed  when:  Always 

Date  of  revision.  “DD”  (Day).  “MM”  (Month). 
“YYYY”  (Year). 

Range:  MM-DD-YYYY 

UPDATE 

NUMBER 

G\UN 

Allowed  when:  Always 

Update  number  of  current  change  that  has  not  been 
incorporated  as  a  revision. 

Range:  0-99 

UPDATE  DATE 

G\UD 

Allowed  when:  Always 

Date  of  update.  “DD”  (Day).  “MM”  (Month). 

“YYYY”  (Year). 

Range:  MM-DD-YYYY 

TEST  NUMBER 

G\TN 

Allowed  when:  Always 

Test  identification. 

Range:  16  characters 

NUMBER  OE 
POINTS  OP 
CONTACT 

G\POC\N 

Allowed  when:  Always 

Number  of  points  of  contact  to  be  given. 

Range:  0-9 

Default:  0 
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Table  9-2. 

General  Information  Group  (G) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Point  of  Contact 

NAME 

G\POCl-n 

Allowed  when:  G\POC\N  >  0 

Identify  the  name  point  of  contact  for  additional 

Range:  24  characters 

information. 

AGENCY 

G\POC2-n 

Allowed  when:  GVPOCVN  >  0 

Identify  the  agency  point  of  contact  for  additional 

Range:  48  characters 

information. 

ADDRESS 

G\POC3-n 

Allowed  when:  GVPOCVN  >  0 

Identify  the  address  point  of  contact  for  additional 

Range:  48  characters 

information. 

TEEEPHONE 

G\POC4-n 

Allowed  when:  G\POC\N  >  0 

Identify  the  telephone  point  of  contact  for  additional 

Range:  20  characters 

information. 

Data  Source  Identification 

NUMBER  OE 

G\DSI\N 

R/R  Ch  10  Status:  R 

Specify  the  number  of  data  sources:  for  RE  telemetry 

DATA  SOURCES 

Allowed  when:  Always 

systems,  give  the  number  of  carriers;  for  tape  or 

Required  when:  Allowed 

storage  recorded  data,  identify  the  number  of  tape  or 

Range:  1-99 

storage  sources. 

DATA  SOURCE  ID 

G\DSI-n 

R/R  Ch  10  Status:  R 

Provide  a  descriptive  name  for  this  source.  Each 

Allowed  when:  GVDSKN  >  0 

source  identifier  must  be  unique. 

Required  when:  Allowed 

Einks  to:  R-x\ID,  T-x\ID,  M-xMD,  V-x\ID 

r 

Range:  32  characters 

DATA  SOURCE 

G\DST-n 

R/R  Ch  10  Status:  R 

Specify  the  type  of  source. 

TYPE 

Allowed  when:  GVDSEN  >  0 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

RE 

Radio  Erequency 

TAP 

Tape 

STO 

Storage 

REP 

Reproducer 

DSS 

Distributed  source 
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Table  9-2.  General  Information  Group  (G) 


Parameter 


Code  Name 


Usage  Attributes 


Definition 


DRS 


OTH 


Direct  source 


Other 


DATA  SOURCE 
PURITY 
ASSIFICATION 


G\DSC-n 


Allowed  when:  GVDSKN  >  0 


Range:  2048  Characters 


Provide  the  classification  of  the  data  for  this  source. 
Provide  a  description  of  the  classification  guide  and 
any  information  concerning  declassification  and/or 
downgrading  in  comments.  For  Digital  Recorder  Data 
Sources,  this  specifies  the  classification  and 
distribution  statements  of  the  data  file  produced  by  the 
Recorder. 


NOTE:  Provide  the  above  three  items  for  each  data  source. 


Test  Information 


TEST  DURATION 


G\TI1 


Allowed  when:  Always 


Range:  0-9999 


Approximate  duration  of  test  in  hours. 


PRE-TEST 

REQUIREMENT 


G\TI2 


Allowed  when:  Always 


Range:  Enumeration 


Indicate  whether  a  pre-test  requirement  is  applicable. 
Provide  details  in  comments. 


Enumeration 


Y 


N 


Description 


Yes 


No 


Default:  N 


POST-TEST 

REQUIREMENT 


G\TI3 


Allowed  when:  Always 


Range:  Enumeration 


Specify  whether  a  post-test  requirement  is  applicable. 
Provide  details  in  comments. 


Enumeration 


Y 


N 


Description 


Yes 


No 


Default:  N 


p:URITY 
^ASSIFICATION 


G\SC 


Allowed  when:  Always 


Range:  2048  Characters 


Provide  the  classification  of  the  TMATS  file.  Provide 
a  description  of  the  classification  guide  and  any 
information  concerning  declassification  and/or 
downgrading  in  comments. 
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Table  9-2.  General  Information  Group  (G) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

TMATS  Checksum 

MESSAGE 

DIGEST/ 

CHECKSUM 

G\SHA 

Allowed  when:  Always 

Provide  a  message  digest  /  checksum  of  the  TMATS. 

The  entire  contents  of  the  TMATS  file  except  the 
characters  from  “G\SHA:”  to  the  following 
(inclusive)  shall  be  used  to  calculate  the  checksum. 

The  value  integer  is  an  algorithm  designator  and  the 
hex  digits  are  the  checksum.  SHA2-256  shall  be 
represented  as  “2-”  followed  by  64  hex  characters.  See 
Subsection  6.2.2.40  for  more  information. 

Range:  integer  followed  by  followed  by  hex 

characters 

Comments 

COMMENTS 

G\COM 

Allowed  when:  Always 

Provide  the  additional  information  requested  or  any 
other  information  desired. 

Range:  1600  characters 
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9.5.3  Transmission  Attributes  (T) 

The  Transmission  attributes  are  presented  graphieally  in  Figure  9-3  and  speeified  in 
Table  9-3.  The  information  eontained  within  this  group  is  used  to  set  up  the  RF  reeeiver  through 
the  detection  and  recovery  of  the  baseband  composite  waveform.  The  format  contains  the 
information  needed  to  configure  the  antenna  and  receiver  subsystems. 

Additional  equipment  inserted  in  a  specific  range  configuration,  such  as  microwave  or 
other  relay,  is  intended  to  be  transparent  to  the  user  and  is  not  described  under  Transmission 
Attributes. 


Because  the  information  is  mutually  exclusive,  only  the  appropriate  FM  or  PM  system 
data  set  is  required  for  a  link. 


Figure  9-3.  Transmission  Attributes  Group  (T) 

Code  Name 

DATA  SOURCE  ID  -  9-16 

(T-x\ID) 

*  Source  RF  Attributes 

TRANSMITTER  ID 

(T-x\TID) 

FREQUENCY 

(T-x\RFI) 

RE  BANDWIDTH 

(T-x\RF2) 

DATA  BANDWIDTH 

(T-x\RF3) 

MODUEATION  TYPE 

(T-x\RF4) 

TOTAE  CARRIER  MODUEATION 

(T-x\RF5) 

POWER  (RADIATED) 

(T-x\RF6) 

9-17 

NUMBER  OE  SUBCARRIERS 

(T-x\SCO\N) 

9-17 

SUBCARRIER  NUMBER 

(T-x\SCOI-n) 

MODUEATION  INDEX 

(T-x\SC02-n) 

MODI 

JEATOR  NON-EINEARITY 

(T-x\RF7) 

9-17 

*Premodulation  Filter 

BANDWIDTH 

(T-x\PMFI) 

SEOPE 

(T-x\PMF2) 

TYPE 

(T-x\PMF3) 

9-18 

*  Transmit  Antenna 

TRANSMIT  ANTENNA  TYPE 

(T-x\ANI) 

TRANSMIT  POEARIZATION 

(T-x\AN2) 

ANTENNA  EOCATION 

(T-x\AN3) 

9-18 

*Antenna  Patterns 

DOCUMENT 

(T-x\AP) 

*Point  of  Contact 

NAME 

(T-x\AP\POCI) 

AGENCY 

(T-x\AP\POC2) 

ADDRESS 

(T-x\AP\POC3) 

TEEEPHONE 

(T-x\AP\POC4) 

9-18 

*  Ground  Station  Attri 

butes 

IF  BANDWIDTH 

(T-x\GSTI) 

BASEBAND  COMPOSITE  BANDWIDTH 

(T-x\GST2) 

9-19 

*Gain  Control 
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OR 

AGC  TIME  CONSTANT 

(T-x\GST3) 

MGC  GAIN  SET  POINT 

(T-x\GST4) 

AFC/APC 

(T-x\GST5) 

TRACKING  BANDWIDTH 

(T-x\GST6) 

9-19 

POLARIZATION  RECEPTION 

(T-x\GST7) 

9-20 

*FM  Systems 

DISCRIMINATOR  BANDWIDTH 

(T-x\EMl) 

DISCRIMINATOR  EINEARITY 

(T-x\EM2) 

9-20 

OR 

*PM  Systems 

PHASE  EOCK  EOOP  BANDWIDTH 

(T-x\PEE) 

*  Comments 

9-20 

COMMENTS 

(T-x\COM) 

*Heading  Only  - 

No  Data  Entry 
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Table  9-3.  Transmission  Attributes  Group  (T) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

DATA  SOURCE  ID 

T-xMD 

Allowed  when:  Always 

Data  source  ID  consistent  with  General  Information 
group. 

Required  when:  defining  Transmitter  attributes 

Einks  from:  G\DSTn 

Einks  to:  M-x\ID 

Range:  32  characters 

Source  RF  Attributes 

TRANSMITTER  ID 

T-x\TID 

Allowed  when:  T-x\ID  specified 

Transmitter  identification. 

Range:  12  characters 

EREQUENCY 

T-x\REl 

Allowed  when:  T-x\ID  specified 

Carrier  frequency,  in  megahertz  (MHz).  If 
programmable,  enter  “P”  and  define  in  comments. 

Range:  6  characters 

RE  BANDWIDTH 

T-x\RE2 

Allowed  when:  T-x\ID  specified 

Total  RE  bandwidth  (-60  decibel  [dB])  of  modulated 
signal,  in  MHz. 

Range:  6  characters 

DATA 

BANDWIDTH 

T-x\RE3 

Allowed  when:  T-x\ID  specified 

Composite  baseband  data  bandwidth  (3  dB),  in 
kilohertz,  (kHz). 

Range:  6  characters 

MODUEATION 

TYPE 

T-x\RE4 

Allowed  when:  T-x\ID  specified 

Define  the  modulation  type. 

Range:  Enumeration 

Enumeration 

Description 

EM 

PM 

BPSK 

DPSK 

QPSK 

EQPSK-B 

EQPSK-JR 

SOQPSK-TG 

MUETI-H-CPM 

OTHR 
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Table  9-3.  Transmission  Attributes  Group  (T) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

TOTAL  CARRIER 
MODULATION 

T-x\RE5 

Allowed  when:  T-x\ID  specified 

Eor  EM  system,  define  total  carrier  deviation,  peak-to- 
peak,  in  kHz.  Eor  PM  system,  define  total  phase 
modulation,  peak-to-peak,  in  radians. 

Range:  6  characters 

POWER 

(RADIATED) 

T-x\RE6 

Allowed  when:  T-x\ID  specified 

Total  transmitted  power  when  modulated,  in  watts. 

Range:  4  characters 

NUMBER  OE 
SUBCARRIERS 

T-x\SCO\N 

Allowed  when:  T-x\ID  specified 

Number  of  subcarriers  in  the  composite  baseband 
waveform,  n.  If  none,  enter  “NO”. 

Range:  0-99,  “NO” 

Default:  NO 

SUBCARRIER 

NUMBER 

T-x\SC01-n 

Allowed  when:  T-x\SCO\N  >  0 

Give  the  IRIG  channel  number  for  the  subcarrier.  If 
nonstandard  subcarrier,  enter  “NO”  and  enter 
frequency  in  the  comments  section  where  n  is  an 
identification  tag  for  the  subcarrier. 

Required  when:  Allowed 

Range:  5  characters 

MODULATION 

INDEX 

T-x\SC02-n 

Allowed  when:  T-x\SCO\N  >  0 

Specify  the  modulation  index  for  each  subcarrier  in  the 
composite  waveform,  as  appropriate. 

Range:  4  characters 

MODULATOR 

NONLINEARITY 

T-x\RE7 

Allowed  when:  T-x\ID  is  specified 

Modulator  nonlinearity,  in  percent. 

Range:  Eloating  point  0-100 

Default:  0 

Premodulation  Filter 

BANDWIDTH 

T-x\PMEl 

Allowed  when:  T-x\ID  is  specified 

Pre-modulation  composite  filter  bandwidth,  3  dB  cut¬ 
off  frequency,  in  kHz. 

Range:  6  characters 

SLOPE 

T-x\PME2 

Allowed  when:  T-x\ID  is  specified 

Pre-modulation  filter  asymptotic  roll-off  slope, 
dB/octave. 

Range:  2  characters 

TYPE 

T-x\PME3 

Allowed  when:  T-x\ID  is  specified 

Specify  the  filter  type. 

Range:  Enumeration 

Enumeration 

Description 

CA 

Constant  amplitude 

CD 

Constant  delay 

OT 

Other 
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Table  9-3.  Transmission  Attributes  Group  (T) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Transmit  Antenna 

TRANSMIT 
ANTENNA  TYPE 

T-x\ANl 

Allowed  when:  T-x\ID  is  specified 

Transmit  antenna  type. 

Range:  16  characters 

TRANSMIT 

POEARIZATION 

T-x\AN2 

Allowed  when:  T-x\ID  is  specified 

Transmit  antenna  polarization. 

Range:  Enumeration 

Enumeration 

Description 

RHCP 

EHCP 

EIN 

linear 

ANTENNA 

EOCATION 

T-x\AN3 

Allowed  when:  T-x\ID  is  specified 

Describe  the  antenna  location. 

Range:  16  characters 

Antenna  Patterns 

DOCUMENT 

T-x\AP 

Allowed  when:  T-x\ID  is  specified 

Identify  document  having  antenna  patterns. 

Range:  16  characters 

Point  of  Contact 

NAME 

T-x\AP\POCl 

Allowed  when:  T-x\ID  is  specified 

Identify  the  name  point  of  contact  for  additional 
information. 

Range:  24  characters 

AGENCY 

T-x\AP\POC2 

Allowed  when:  T-x\ID  is  specified 

Identify  the  agency  point  of  contact  for  additional 
information. 

Range:  48  characters 

ADDRESS 

T-x\AP\POC3 

Allowed  when:  T-x\ID  is  specified 

Identify  the  address  point  of  contact  for  additional 
information. 

Range:  48  characters 

TEEEPHONE 

T-x\AP\POC4 

Allowed  when:  T-x\ID  is  specified 

Identify  the  telephone  point  of  contact  for  additional 
information. 

Range:  20  characters 

Ground  Station  Attributes 

IE  BANDWIDTH 

T-x\GSTl 

Allowed  when:  T-x\ID  is  specified 

Define  IE  bandwidth  (3  dB)  in  MHz. 

Range:  6  characters 

BASEBAND 

COMPOSITE 

BANDWIDTH 

T-x\GST2 

Allowed  when:  T-x\ID  is  specified 

Define  the  cutoff  frequency  (3  dB),  of  the  output  filter, 
in  kHz. 

Range:  6  characters 
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Table  9-3.  Transmission  Attributes  Group  (T) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Gain  Control 

AGC  TIME 

T-x\GST3 

Allowed  when:  T-x\ID  is  specified 

Specify  the  AGC  time  constant  desired  in  milliseconds. 

CONSTANT 

Range:  4  characters 

MGC  GAIN  SET 

T-x\GST4 

Allowed  when:  T-x\ID  is  specified 

Provide  the  manual  gain  control  set  point  in  terms  of 

POINT 

Range:  6  characters 

received  signal  strength,  dBm. 

AEC/APC 

T-x\GST5 

Allowed  when:  T-x\ID  is  specified 

Specify  automatic  frequency  control,  automatic  phase 

Range:  Enumeration 

control,  or  none. 

Enumeration 

Description 

AEC 

automatic  frequency 
control 

APC 

automatic  phase  control 

NON 

none 

Default:  NON 

TRACKING 

T-x\GST6 

Allowed  when:  T-x\ID  is  specified 

Specify  tracking  loop  bandwidth,  in  hertz  (Hz). 

BANDWIDTH 

Range:  4  characters 

POEARIZATION 

T-x\GST7 

Allowed  when:  T-x\ID  is  specified 

Specify  polarization  to  be  used. 

RECEPTION 

Range:  Enumeration 

Enumeration 

Description 

RHCP 

EHCP 

BOTH 

Both  with  diversity  combining: 

B&DPR 

Pre-detection 

B&DPO 

Post-detection 

Diversity  combining  only: 

PRE-D 

Pre-detection 

POS-D 

Post-detection 

OTHER 

Specify  in  comments 
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Table  9-3.  Transmission  Attributes  Group  (T) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

FM  Systems 

DISCRIMINATOR 

BANDWIDTH 

T-x\EMI 

Allowed  when:  T-x\ID  is  specified 

Specify  the  discriminator  bandwidth  required,  in  MHz. 

Range:  4  characters 

DISCRIMINATOR 

LINEARITY 

T-x\EM2 

Allowed  when:  T-x\ID  is  specified 

Specify  the  required  linearity  over  the  bandwidth 
specified. 

Range:  4  characters 

PM  Systems 

PHASE  EOCK 

EOOP 

BANDWIDTH 

T-x\PEE 

Allowed  when:  T-x\ID  is  specified 

Specify  the  phase-locked  loop  bandwidth. 

Range:  4  characters 

Comments 

COMMENTS 

T-x\COM 

Allowed  when:  T\ID  is  specified 

Provide  the  additional  information  requested  or  any 
other  information  desired. 

Range:  1600 
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9.5.4  Recorder-Reproducer  Attributes  (R) 

This  group  describes  the  attributes  required  when  the  data  source  is  a  magnetic  tape  as 
specified  in  Annex  A. 2  or  a  data  storage  device  as  specified  in  Chapter  10.  In  the  case  of  the 
tape  data  link  identification,  each  data  source  must  be  identified.  In  some  cases,  the  data  source 
identification  may  be  identical,  particularly  when  the  same  information  has  been  received  from 
different  receiver  sites,  on  different  polarizations,  or  on  different  carriers  for  redundancy 
purposes.  Some  of  the  information  requested  will  be  available  only  from  the  recording  site  or 
the  dubbing  location. 

Figure  9-4  indicates  the  information  required.  Various  categories  of  information  have 
been  included.  In  the  data  section  of  the  attributes,  it  will  be  necessary  to  repeat  the  items  until 
all  of  the  data  sources,  including  the  multiple  tracks,  have  been  defined  that  contain  ground 
station  data  of  interest.  Table  9-4  defines  the  information  required.  Any  nonstandard  tape 
recordings  will  require  explanation  in  the  comments  and  may  require  supplemental  definition. 

Recorder-reproducer  filtering  and  post-process  data  filtering  and  overwrite  will  use 
TMATS  attributes  to  describe  the  requirements.  Recorder-reproducer  channel  types  that  support 
filtering  and  overwrite  will  define  these  attributes.  The  PCM  channels  will  use  R,  P,  and  D 
attributes  and  the  bus  channels  will  use  R  and  B  attributes  to  define  filtering  and  overwrite 
definitions. 


Figure  9-4.  Recorder- Reproducer  Attributes  Group  (R) 

Code  Name 

DATA  SOURCE  ID  -  9-30 

(R-x\ID) 

9-30 

RECORDER-REPRODUCER  ID 

(R-x\RID) 

RECORDER-REPRODUCER  DESCRIPTION 

(R-x\Rl) 

9-30 

*Recorder- Reproducer  Media  Characteristics 

RECORDER-REPRODUCER  MEDIA  TYPE 

(R-x\TCl) 

RECORDER-REPRODUCER  MEDIA  MEG 

(R-x\TC2) 

RECORDER-REPRODUCER  MEDIA  CODE 

(R-x\TC3) 

RECORDER-REPRODUCER  MEDIA  EOCATION 

(R-x\RME) 

EXTERNAE  RMM  BUS  SPEED 

(R-x\ERBS) 

TAPE  WIDTH 

(R-x\TC4) 

TAPE  HOUSING 

(R-x\TC5) 

TYPE  OE  TRACKS 

(R-x\TT) 

NUMBER  OE  TRACKS/CHANNEES 

(R-x\N) 

RECORD  SPEED 

(R-x\TC6) 

DATA  PACKING  DENSITY 

(R-x\TC7) 

TAPE  REWOUND 

(R-x\TC8) 

NUMBER  OE  SOURCE  BITS 

(R-x\NSB) 

9-33 

*Recorder- Reproducer  Information 

RECORDER-REPRODUCER  MANUEACTURER 

(R-x\RH) 

RECORDER-REPRODUCER  MODEE 

(R-x\RI2) 

ORIGINAE  RECORDING 

(R-x\RI3) 

ORIGINAE  RECORDING  DATE  AND  TIME 

(R-x\RI4) 

9-33 

*  Creating  Organization  Point  of  Contact 

NAME 

(R-x\POCl) 
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AGENCY 

(R-x\POC2) 

ADDRESS 

(R-x\POC3) 

TELEPHONE 

(R-x\POC4) 

DATE  AND  TIME  OF  COPY 

(R-x\RI5) 

*  Copying  Organization  Point  of  Contact 

NAME 

(R-x\DPOCI) 

AGENCY 

(R-x\DPOC2) 

ADDRESS 

(R-x\DPOC3) 

TELEPHONE 

(R-x\DPOC4) 

POST  PROCESS  MODIFIED  RECORDING 

(R-x\RI6) 

POST  PROCESS  MODIFICATION  TYPE 

(R-x\RI7) 

DATE  AND  TIME  OF  MODIFICATION 

(R-x\RI8) 

^Modifying  Organization  Point  of  Contact 

NAME 

(R-x\MPOCI) 

AGENCY 

(R-x\MPOC2) 

ADDRESS 

(R-x\MPOC3) 

TELEPHONE 

(R-x\MPOC4) 

O 

u 

STINUOUS  RECORDING  ENABLED 

(R-x\CRE) 

RECORDER-REPRODUCER  SETUP  SOURCE 

(R-x\RSS) 

RECORDER  SERIAL  NUMBER 

(R-x\RI9) 

RECORDER  FIRMWARE  REVISION 

(R-x\RH0) 

NU] 

VIBER  OF  MODULES 

(R-x\RIM\N) 

MODULE  ID 

(R-x\RIMI-n) 

MODULE  SERIAL  NUMBER 

(R-x\RIMS-n) 

MODULE  FIRMWARE  REVISION 

(R-x\RIMF-n) 

NU] 

VIBER  OF  RMMS 

(R-x\RMM\N) 

RMM  IDENTIFIER 

(R-x\RMMID-n) 

RMM  SERIAL  NUMBER 

(R-x\RMMS-n) 

RMM  FIRMWARE  REVISION 

(R-x\RMMF-n) 

*  Recorder- Reproducer  Ethernet  Interfaces 

NUMBER  OF  ETHERNET  INTERFACES 

(R-x\EI\N) 

ETHERNET  INTERFACE  NAME 

(R-x\EINM-n) 

PHYSICAL  ETHERNET  INTERFACE 

(R-x\PEIN-n) 

ETHERNET  INTERFACE  LINK  SPEED 

(R-x\EILS-n) 

ETHERNET  INTERFACE  TYPE 

(R-x\EIT-n) 

ETHERNET  INTERFACE  IP  ADDRESS 

(R-x\EIIP-n) 

NUMBER  OF  ETHERNET  INTERFACE 
PORTS 

(R-x\EIIP\N-n) 

PORT  ADDRESS 

(R-x\EI\PA-n-m) 

PORT  TYPE 

(R-x\EI\PT-n-m) 

*  Recorder- Reproducer  Channel  Group  Streams 

NUMBER  OF  CHANNEL  GROUPS 

(R-x\CG\N) 

CHANNEL  GROUP  NAME 

(R-x\CGNM-n) 

CHANNEL  GROUP  STREAM  NUMBER 

(R-x\CGSN-n) 

NUMBER  OF  GROUP  CHANNELS  (R-x\CGCH\N-n) 


9-22 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  9,  July  2017 


GROUP  CHANNEL  NUMBER 

(R-x\CGCN-n-m) 

*  Recorder-Reproducer  Drives  and  Volumes 

NUMBER  OF  DRIVES 

(R-x\DR\N) 

DRIVE  NAME 

(R-x\DRNM-n) 

DRIVE  NUMBER 

(R-x\DRN-n) 

DRIVE  BLOCK  SIZE 

(R-x\DRBS-n) 

NUMBER  OF  DRIVE  VOLUMES 

(R-x\DRVL\N-n) 

VOLUME  NAME 

(R-xWLNM-n-m) 

VOLUME  NUMBER 

(R-xWLN-n-m) 

VOLUME  BLOCKS  TO  ALLOCATE 

(R-xWLBA-n-m) 

VOLUME  NUMBER  OF  BLOCKS 

(R-xWLNB-n-m) 

*  Recorder-Reproducer 

Stream/Drive- Volume  Links 

NUMBER  OF  LINKS 

(R-x\L\N) 

LINK  NAME 

(R-x\LNM-n) 

LINK  SOURCE  STREAM  NAME 

(R-x\LSNM-n) 

LINK  SOURCE  STREAM  NUMBER 

(R-x\LSSN-n) 

LINK  DESTINATION  DRIVE  NUMBER 

(R-x\LDDN-n) 

LINK  DESTINATION  VOLUME  NUMBER 

(R-x\LDVN-n) 

*  Recorder-Reproducer 

Ethernet  Interface  Publishing  Links 

NUMBER  OF  ETHERNET  PUBLISHING 

LINKS 

(R-x\EPL\N) 

LINK  NAME 

(R-x\EPL\LNM-n) 

LINK  SOURCE  STREAM  NAME 

(R-x\EPL\LSNM-n) 

LINK  SOURCE  STREAM  NUMBER 

(R-x\EPL\LSSN-n) 

LINK  DESTINATION  ETHERNET 

INTERFACE  IP  ADDRESS 

(R-x\EPL\LDEIP-n) 

LINK  DESTINATION  ETHERNET 

INTERFACE  PORT  ADDRESS 

(R-x\EPL\LDEPA-n) 

*  Computer- Generated  Data  Packet,  User-Defined 

Definition 

USER-DEFINED  CHANNEE  ID 

(R-x\UD\TKI) 

9-42 

*Recording  Event  Definitions 

RECORDING  EVENTS  ENABEED 

(R-x\EV\E) 

RECORDING  EVENTS  CHANNEE  ID 

(R-x\EV\TKI) 

NUMBER  OF  RECORDING  EVENTS 

(R-x\EV\N) 

RECORDER  INTERNAE  EVENTS  ENABEED 

(R-x\EV\IEE) 

9-43 

^Recording  Event 

EVENT  ID 

(R-x\EV\ID-n) 

EVENT  DESCRIPTION 

(R-x\EV\D-n) 

EVENT  DATA  PROCESSING  ENABLED 

(R-x\EV\EDP-n) 

EVENT  TYPE 

(R-x\EV\T-n) 

9-44 

EVENT  PRIORITY 

(R-x\EV\P-n) 

EVENT  CAPTURE  MODE 

(R-x\EV\CM-n) 
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EVENT  INITIAL  CAPTURE 

(R-x\EV\IC-n) 

RECORDING  EVENT  LIMIT  COUNT 

(R-x\EV\LC-n) 

EVENT  TRIGGER  MEASUREMENT  SOURCE 

(R-x\EV\MS-n) 

EVENT  TRIGGER  MEASUREMENT  NAME 

(R-x\EV\MN-n) 

EVENT  PROCESSING  MEASUREMENT 

DATA  LINK  NAME 

(R-x\EV\DLN-n) 

NUMBER  OE  MEASUREMENTS  TO 

PROCESS 

(R-x\EV\PM\N-n) 

MEASUREMENT  NAME  TO  PROCESS 

(R-x\EV\PM\MN-n-m) 

PRE-EVENT  PROCESSING  DURATION 

(R-x\EV\PM\PRE-n-m) 

POST-EVENT  PROCESSING  DURATION 

(R-x\EV\PM\PST-n-m) 

9-46 

*Recording  Index 

RECORDING  INDEX  ENABEED 

(R-x\IDX\E) 

RECORDING  INDEX  CHANNEE  ID 

(R-x\IDX\TKI) 

RECORDING  INDEX  TYPE 

(R-x\IDX\IT) 

9-46 

*  Time  Index  Type  Attribute 

INDEX  TIME  VALUE 

(R-x\IDX\ITV) 

OR 

*  Count  Index  Type  Attribute 

INDEX  COUNT  VALUE 

(R-x\IDX\ICV) 

9-47 

*MIL-STD-1553  Recorder  Control 

MESSAGE  MONITOR  RECORD  CONTROE 
ENABEED 

(R-x\MRC\E) 

CHANNEL  ID  NUMBER 

(R-x\MRC\ID) 

MESSAGE  RECORD  CONTROL  TYPE 

(R-x\MRC\RCT) 

STOP-PAUSE  COMMAND  WORD 

(R-x\MRC\SPM) 

START-RESUME  COMMAND  WORD 

(R-x\MRC\SRM) 

*Data 

TRACK  NUMBER/  CHANNEL  ID 

(R-x\TKI-n) 

RECORDING  TECHNIQUE 

(R-x\TK2-n) 

INPUT  STREAM  DERANDOMIZATION 

(R-x\IDDR-n) 

9-48 

DATA  SOURCE  ID 

(R-x\DSI-n) 

9-48 

DATA  DIRECTION 

(R-x\TK3-n) 

RECORDER  PHYSICAL  CHANNEL  NUMBER 

(R-x\TK4-n) 

CHANNEL  ENABLE 

(R-x\CHE-n) 

CHANNEL  DATA  TYPE 

(R-x\CDT-n) 

CHANNEL  DATA  LINK  NAME 

(R-x\CDLN-n) 

SECONDARY  HEADER  TIME  EORMAT 

(R-x\SHTE-n) 

*Data  Type  Attributes 

9-50 

*P( 

2M  Data  Type  Attributes 

PCM  DATA  TYPE  EORMAT 

(R-x\PDTE-n) 

DATA  PACKING  OPTION 

(R-x\PDP-n) 

RECORDER  POLARITY  SETTING 

(R-x\RPS-n) 

INPUT  CLOCK  EDGE 

(R-x\ICE-n) 

INPUT  SIGNAL  TYPE 

(R-x\IST-n) 

INPUT  THRESHOLD 

(R-x\ITH-n) 
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INPUT  TERMINATION 

(R-x\ITM-n) 

PCM  VIDEO  TYPE  EORMAT 

(R-x\PTE-n) 

PCM  RECORDER-REPRODUCER 

MINOR  ERAME  EIETERING  ENABEED 

(R-x\MEE\E-n) 

PCM  POST  PROCESS  OVERWRITE  AND 
EIETERING  ENABEED 

(R-x\POE\E-n) 

PCM  POST  PROCESS  OVERWRITE  AND 
EIETERING  TYPE 

(R-x\POE\T-n) 

MINOR  ERAME  EIETERING 

DEEINITION  TYPE 

(R-x\MEE\EDT-n) 

NUMBER  OE  MINOR  ERAME 

EIETERING  DEEINITIONS 

(R-x\MEE\N-n) 

EIETERED  MINOR  ERAME  NUMBER 

(R-x\MEE\MEN-n-m) 

NUMBER  OE  SEEECTED 
MEASUREMENT  OVERWRITE 
DEEINITIONS 

(R-x\SME\N-n) 

SEEECTED  MEASUREMENT  NAME 

(R-x\SME\SMN-n-m) 

MEASUREMENT  OVERWRITE  TAG 

(R-x\SME\MEOT-n-m) 

9-55 

OR 

*MIL-STD-1553  Bus  Data  Type  Attributes 

MIE-STD-I553  BUS  DATA  TYPE 
EORMAT 

(R-x\BTE-n) 

MIE-STD-I553  RECORDER- 
REPRODUCER  EIETERING  ENABEED 

(R-x\MRE\E-n) 

MIE-STD-I553  POST  PROCESS 
OVERWRITE  AND  EIETERING 

ENABEED 

(R-x\MOE\T-n) 

MIE-STD-I553  MESSAGE  EIETERING 
DEEINITION  TYPE 

(R-x\MED\EDT-n) 

NUMBER  OE  MESSAGE  EIETERING 
DEEINITIONS 

(R-x\MED\N-n) 

MESSAGE  NUMBER 

(R-x\MED\MID-n-m) 

MESSAGE  TYPE 

(R-x\MED\MT-n-m) 

COMMAND  WORD  ENTRY 

(R-x\CWE-n-m) 

COMMAND  WORD 

(R-x\CMD-n-m) 

REMOTE  TERMINAE  ADDRESS 

(R-x\MED\TRA-n-m) 

TRANSMIT/RECEIVE  MODE 

(R-x\MED\TRM-n-m) 

SUBTERMINAE  ADDRESS 

(R-x\MED\STA-n-m) 

DATA  WORD  COUNT/MODE  CODE 

(R-x\MED\DWC-n-m) 

RECEIVE  COMMAND  WORD  ENTRY 

(R-x\RCWE-n-m) 

RECEIVE  COMMAND  WORD 

(R-x\RCMD-n-m) 

RT/RT  REMOTE  TERMINAE  ADDRESS 

(R-x\MED\RTRA-n-m) 

RT/RT  SUBTERMINAE  ADDRESS 

(R-x\MED\RSTA-n-m) 

RT/RT  DATA  WORD  COUNT 

(R-x\MED\RDWC-n-m) 
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NUMBER  OF  SELECTED 
MEASUREMENT  OVERWRITE 
DEFINITIONS 

(R-x\BME\N-n) 

SELECTED  MEASUREMENT  NAME 

(R-x\BME\SMN-n-m) 

MEASUREMENT  OVERWRITE  TAG 

(R-x\BME\MFOT-n-m) 

9-59 

OR 

*  Analog  Data  Type  Attributes 

ANALOG  DATA  TYPE  FORMAT 

(R-x\ATF-n) 

NUMBER  OF  ANALOG  CHANNELS/PKT 

(R-x\ACH\N-n) 

DATA  PACKING  OPTION 

(R-x\ADP-n) 

SAMPLE  RATE 

(R-x\ASR-n) 

SUB  CHANNEL  ENABLED 

(R-x\AMCE-n-m) 

NUMBER  OF  SUB  CHANNEL  ENABLED 

(R-x\AMCN-n) 

9-60 

MEASUREMENT  NAME 

(R-x\AMN-n-m) 

DATA  LENGTH 

(R-x\ADL-n-m) 

BIT  MASK 

(R-x\AMSK-n-m) 

MEASUREMENT  TRANSFER  ORDER 

(R-x\AMTO-n-m) 

SAMPLE  FACTOR 

(R-x\ASF-n-m) 

SAMPLE  FILTER  3DB  BANDWIDTH 

(R-x\ASBW-n-m) 

AC/DC  COUPLING 

(R-x\ACP-n-m) 

RECORDER  INPUT  IMPEDANCE 

(R-x\AII-n-m) 

INPUT  CHANNEL  GAIN 

(R-x\AGTn-m) 

INPUT  FULL  SCALE  RANGE 

(R-x\AFSI-n-m) 

INPUT  OFFSET  VOLTAGE 

(R-x\AOVI-n-m) 

RECORDED  ANALOG  FORMAT 

(R-x\AF-n-m) 

INPUT  TYPE 

(R-x\AIT-n-m) 

AUDIO 

(R-x\AV-n-m) 

AUDIO  FORMAT 

(R-x\AVF-n-m) 

9-63 

OR 

*Discrete  Data  Type  Attributes 

DISCRETE  DATA  TYPE  FORMAT 

(R-x\DTF-n) 

DISCRETE  MODE 

(R-x\DMOD-n) 

SAMPLE  RATE 

(R-x\DSR-n) 

NUMBER  OF  DISCRETE 
MEASUREMENTS 

(R-x\NDM\N-n) 

MEASUREMENT  NAME 

(R-x\DMN-n-m) 

BIT  MASK 

(R-x\DMSK-n-m) 

MEASUREMENT  TRANSFER  ORDER 

(R-x\DMTO-n-m) 

9-65 

OR 

*A] 

RING  429  Bus  Data  Type  Attributes 

ARINC  429  BUS  DATA  TYPE  FORMAT 

(R-x\ABTF-n) 

NUMBER  OF  ARINC  429  SUB¬ 
CHANNELS 

(R-x\NAS\N-n) 

ARINC  429  SUB-CHANNEL  NUMBER 

(R-x\ASN-n-m) 

ARINC  429  SUB-CHANNEL  NAME 

(R-x\ANM-n-m) 

9-66 

OR 

*Video  Data  Type  Attributes 

VIDEO  DATA  TYPE  FORMAT 

(R-xWTF-n) 

MPEG-2  CHANNEL  XON2  FORMAT 

(R-xWXF-n) 

9-26 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  9,  July  2017 


VIDEO  SIGNAL  TYPE 

(R-xWST-n) 

VIDEO  SIGNAL  EORMAT  TYPE 

(R-xWSE-n) 

VIDEO  CONSTANT  BIT  RATE 

(R-x\CBR-n) 

VIDEO  VARIABLE  PEAK  BIT  RATE 

(R-xWBR-n) 

VIDEO  ENCODING  DELAY 

(R-xWED-n) 

OVERLAY  ENABLED 

(R-x\VCO\OE-n) 

OVERLAY  X  POSITION 

(R-x\VCO\X-n) 

OVERLAY  Y  POSITION 

(R-x\VCO\Y-n) 

OVERLAY  EVENT  TOGGLE  ENABLED 

(R-x\VCO\OET-n) 

OVERLAY  EORMAT 

(R-x\VCO\OLE-n) 

OVERLAY  BACKGROUND 

(R-x\VCO\OBG-n) 

ANALOG  AUDIO  CHANNEL  INPUT 
LETT 

(R-x\ASEASL-n) 

ANALOG  AUDIO  CHANNEL  INPUT 
RIGHT 

(R-x\ASEASR-n) 

VIDEO  DATA  ALIGNMENT 

(R-xWDA-n) 

9-69 

OR 

*Time  Data  Type  Attributes 

TIME  DATA  TYPE  EORMAT 

(R-x\TTE-n) 

TIME  EORMAT 

(R-x\TEMT-n) 

TIME  SOURCE 

(R-x\TSRC-n) 

9-70 

OR 

*Image  Data  Type  Attributes 

IMAGE  DATA  TYPE  EORMAT 

(R-x\ITE-n) 

STILL  IMAGE  TYPE 

(R-x\SIT-n) 

DYNAMIC  IMAGE  EORMAT 

(R-x\DIE-n) 

IMAGE  TIME  STAMP  MODE 

(R-x\ITSM-n) 

DYNAMIC  IMAGE  ACQUISITION 

MODE 

(R-x\DIAM-n) 

IMAGE  ERAME  RATE 

(R-x\IER-n) 

PRE-TRIGGER  ERAMES 

(R-x\PTG-n) 

TOTAL  ERAMES 

(R-x\TOTE-n) 

EXPOSURE  TIME 

(R-x\EXP-n) 

SENSOR  ROTATION 

(R-x\ROT-n) 

SENSOR  GAIN  VALUE 

(R-x\SGV-n) 

SENSOR  AUTO  GAIN 

(R-x\SAG-n) 

SENSOR  WIDTH 

(R-x\ISW-n) 

SENSOR  HEIGHT 

(R-x\ISH-n) 

MAX  IMAGE  WIDTH 

(R-x\MIW-n) 

MAX  IMAGE  HEIGHT 

(R-x\MIH-n) 

IMAGE  WIDTH 

(R-x\IW-n) 

IMAGE  HEIGHT 

(R-x\IH-n) 

IMAGE  OEESET  X 

(R-x\IOX-n) 

IMAGE  OEESET  Y 

(R-x\IOY-n) 

LINE  PITCH 

(R-x\ILP-n) 

BINNING  HORIZONTAL 

(R-x\IBH-n) 

BINNING  VERTICAL 

(R-x\IBV-n) 
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DECIMATION  HORIZONTAL 

(R-x\IDH-n) 

DECIMATION  VERTICAL 

(R-x\IDV-n) 

REVERSE  X 

(R-x\IRX-n) 

REVERSE  Y 

(R-x\IRY-n) 

PIXEL  DYNAMIC  RANGE  MINIMUM 

(R-x\IPMN-n) 

PIXEL  DYNAMIC  RANGE  MAXIMUM 

(R-x\IPMX-n) 

TEST  IMAGE  TYPE 

(R-x\TIT-n) 

9-75 

OR 

*UART  Data  Type  Attributes 

UART  DATA  TYPE  EORMAT 

(R-x\UTE-n) 

NUMBER  OE  UART  SUB-CHANNELS 

(R-x\NUS\N-n) 

UART  SUB-CHANNEL  NUMBER 

(R-x\USCN-n-m) 

UART  SUB-CHANNEL  NAME 

(R-x\UCNM-n-m) 

UART  SUB-CHANNEL  BAUD  RATE 

(R-x\UCR-n-m) 

UART  SUB-CHANNEL  BITS  PER  WORD 

(R-x\UCB-n-m) 

UART  SUB-CHANNEL  PARITY 

(R-x\UCP-n-m) 

UART  SUB-CHANNEL  STOP  BIT 

(R-x\UCS-n-m) 

UART  SUB-CHANNEL  INTERLACE 

(R-x\UCIN-n-m) 

UART  SUB-CHANNEL  BLOCK  SIZE 

(R-x\UCBS-n-m) 

UART  SUB-CHANNEL  SYNC  WORD 

(R-x\UCSL-n-m) 

LENGTH 

UART  SUB-CHANNEL  BLOCK  SYNC 

(R-x\UCSV-n-m) 

VALUE 

UART  SUB-CHANNEL  BLOCK  RATE 

(R-x\UCBR-n-m) 

9-77 

OR 

^Message  Data  Type  Attributes 

MESSAGE  DATA  TYPE  EORMAT 

(R-x\MTE-n) 

NUMBER  OE  MESSAGE  SUB- 

(R-x\NMS\N-n) 

CHANNELS 

MESSAGE  SUB-CHANNEL  NUMBER 

(R-x\MSCN-n-m) 

MESSAGE  SUB-CHANNEL  NAME 

(R-x\MCNM-n-m) 

9-78 

OR 

*IEEE-1394  Data  Type  Attributes 

IEEE- 1 394  DATA  TYPE  EORMAT 

(R-x\IETE-n) 

9-78 

OR 

^Parallel  Data  Type  Attributes 

PARALLEL  DATA  TYPE  EORMAT 

(R-x\PLTE-n) 

9-78 

OR 

*E1 

hernet  Data  Type  Attributes 

ETHERNET  DATA  TYPE  EORMAT 

(R-x\ENTE-n) 

NUMBER  OE  ETHERNET  NETWORKS 

(R-x\NNET\N-n) 

ETHERNET  NETWORK  NUMBER 

(R-x\ENBR-n-m) 

ETHERNET  NETWORK  NAME 

(R-x\ENAM-n-m) 

9-79 

OR 

*TSPI/CTS  Data  Type  Attributes 

TSPECTS  DATA  TYPE  EORMAT 

(R-x\TDTE-n) 

OR 

*CAN  Bus  Data  Type  Attributes 

CAN  BUS  DATA  TYPE  EORMAT 

(R-x\CBTE-n) 

NUMBER  OE  CAN  BUS  SUB- 

(R-x\NCB\N-n) 

CHANNELS 

CAN  BUS  SUB-CHANNEL  NUMBER 

(R-x\CBN-n-m) 
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CAN  BUS  SUB-CHANNEE  NAME 

(R-x\CBM-n-m) 

CAN  BUS  BIT  RATE 

(R-x\CBBS-n-m) 

9-80 

OR 

*Fibre  Channel  Data  Type  Attributes 

EIBRE  CHANNEE  DATA  TYPE  EORMAT 

(R-x\ECTE-n) 

EIBRE  CHANNEE  SPEED 

(R-x\ECSP-n) 

9-81 

OR 

^Telemetry  Output  Attributes 

OUTPUT  STREAM  NAME 

(R-x\OSNM-n) 

STREAM  ID 

(R-x\SID-n) 

CONEIGURATION  HASH  RATE 

(R-x\HRATE-n) 

CONEIGURATION  PACKET  RATE 

(R-x\CRATE-n) 

9-81 

*Reference  Track 

NUMBER  OE  REEERENCE  TRACKS 

(R-x\RT\N) 

TRACK  NUMBER 

(R-x\RTl-n) 

REEERENCE  EREQUENCY 

(R-x\RT2-n) 

9-82 

*  Comments 

COMMENTS 

(R-x\COM) 

*Heading  Only  -  No  Data  Entry 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 


Parameter 

Code  Name 

Usage  Attributes 

Definition 

DATA  SOURCE  ID 

R-xMD 

R/R  Ch  10  Status:  R 

Data  source  ID  consistent  with  General 
Information  group. 

Allowed  when:  Always 

Einks  from:  GVDSTn 

Required  when:  defining  a  recorder 

Range:  32  characters 

RECORDER- 
REPRODUCER  ID 

R-x\RID 

R/R  Ch  10  Status:  R 

Recorder-reproducer  identification. 

Allowed  when:  R\ID  is  specified 

Required  when:  Allowed 

Range:  32  characters 

RECORDER- 

REPRODUCER 

DESCRIPTION 

R-x\RI 

Allowed  when:  R\ID  is  specified 

Recorder-reproducer  description. 

Range:  32  characters 

Recorder- Reproducer  Media  Characteristics 


RECORDER- 

R-x\TCl 

Allowed  when:  R\ID  is  specified 

Specify  the  recorder-reproducer  media  type. 

REPRODUCER 

Range:  Enumeration 

MEDIA  TYPE 

Enumeration 

Description 

ANAE 

Analog 

CASS 

Cassette 

HDDR 

High  Density  Digital  Recorder 

PARA 

Parallel 

SSR 

Solid  State  Recorder 

MD 

Magnetic  Disk 

N 

None,  Data  Publishing  Only 

OTHR 

Other,  define  in  comments 

RECORDER- 

R-x\TC2 

Allowed  when:  RV 

rCl  is  not  “N” 

Name  of  manufacturer  of  the  recorder- 

REPRODUCER 

MEDIA 

MANUEACTURER 

Range:  8  characters 

reproducer  media. 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

RECORDER- 

R-x\TC3 

Allowed  when:  R\TC1  is  not  “N” 

Specify  manufacturer’s  recorder-reproducer 

REPRODUCER 
MEDIA  CODE 

Range:  8  characters 

media  designation  code. 

RECORDER- 

R-x\RME 

R/R  Ch  10  Status:  R 

Indicate  the  location  of  the  recorder-reproducer 

REPRODUCER 

Allowed  when:  R\TC1  is  not  “N” 

media. 

MEDIA 

Required  when:  Allowed 

EOCATION 

Range:  Enumeration 

Enumeration 

Description 

I 

Internal 

E 

External 

B 

Both  internal  and  external 

EXTERNAE  RMM 

R-x\ERBS 

R/R  Ch  10  Status: 

RO 

Indicate  the  speed  of  an  external  RMM  IEEE- 

BUS  SPEED 

Allowed  when:  R\TC1  is  not  “N” 

1394b  bus. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

AUTO 

Speed  set  by  host  device 

SlOO 

100  Mbps 

S200 

200  Mbps 

S400 

400  Mbps 

S800 

800  Mbps 

SI  600 

1600  Mbps 

S3200 

3200  Mbps 

TAPE  WIDTH 

R-x\TC4 

Allowed  when:  RC 

rCl  is  “ANAE”  or  “CASS” 

Physical  dimension  of  tape  width,  in  inches. 

Range:  0.00  -  9.99 

TAPE  HOUSING 

R-x\TC5 

Allowed  when:  R\TC1  is  “ANAE”  or  “CASS” 

State  the  reel  size. 

Range:  Enumeration 

Enumeration 

Description 

10.5 

10.5  Inches 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

14.0 

14.0  Inches 

15.0 

15.0  Inches 

16.0 

16.0  Inches 

12.65 

12.65  Millimeters 

19.0 

19.0  Millimeters 

OTHER 

Other 

TYPE  OF  TRACKS 

R-x\TT 

Allowed  when:  RC 

rCl  is  “ANAE”  or  “CASS” 

State  the  type  of  tracks  on  the  tape. 

Range:  Enumeration 

Enumeration 

Description 

EO 

Eongitudinal 

RO 

Rotary 

NUMBER  OF 

TRACKS/ 

CHANNEES 

R-x\N 

R/R  Ch  10  Status: 

R 

State  the  number  of  tracks  on  the  tape  or  the 
number  of  channels  on  the  storage  media. 

Allowed  when:  R\TC1  is  not  “N” 

Required  when:  Allowed 

Range:  1-65536 

RECORD  SPEED 

R-x\TC6 

Allowed  when:  R\TC1  is  “ANAE”  or  “CASS” 

State  record  speed  (inches/second). 

Range:  00.0  -  99.9 

DATA  PACKING 
DENSITY 

R-x\TC7 

Allowed  when:  R\TC1  is  “ANAE”  or  “CASS” 

State  recording  system  bandwidth. 

Range:  Enumeration 

Enumeration 

Description 

IM 

Intermediate  band 

WB 

Wide  band 

DD 

Double  density 

OT 

Other 

TAPE  REWOUND 

R-x\TC8 

Allowed  when:  RC 

rCl  is  “ANAE”  or  “CASS” 

Name  of  tape  rewound. 

Range:  Enumeration 

Enumeration 

Description 

Y 

Yes 

N 

No 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

NUMBER  OF 
SOURCE  BITS 

R-x\NSB 

R/R  Ch  10  Status:  R 

Number  of  most  significant  bits  (msbs)  of  the 
channel  ID  used  for  multiplexer  source  ID. 
Specify  0  for  one  source. 

Allowed  when:  R\ID  is  specified 

Range:  0-13 

Recorder- Reproducer  Information 

RECORDER- 

REPRODUCER 

MANUFACTURER 

R-x\RII 

Allowed  when:  R\ID  is  specified 

Name  of  recorder-reproducer  device 
manufacturer. 

Range:  64  characters 

RECORDER- 

REPRODUCER 

MODEE 

R-x\RI2 

Allowed  when:  R\ID  is  specified 

Manufacturer’s  model  number  of  recorder- 
reproducer  device  used  to  create  the  recording. 

Range:  64  characters 

ORIGINAE 

RECORDING 

R-x\RI3 

R/R  Ch  10  Status:  R 

Indicate  if  this  is  an  original  recording  from  the 
source. 

Allowed  when:  R\TC1  is  not  “N” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

Y 

Yes 

N 

No 

ORIGINAE 

RECORDING 

DATE  AND  TIME 

R-x\RI4 

Allowed  when:  RV 

rCl  is  not  “N” 

Date  and  time  original  recording  was  created 
using  the  format  defined  in  Subsection  9.5.1. 
Example  08-19-2014-17-33-59. 

Range:  Custom  date  and  time 

Creating  Organization  Point  of  Contact 

CREATING 
ORGANIZATION 
POC  NAME 

R-x\POCI 

Allowed  when:  R\TC1  is  not  “N” 

Identify  the  creating  organization  POC  name 
for  additional  information 

Range:  24  characters 

CREATING 
ORGANIZATION 
POC  AGENCY 

R-x\POC2 

Allowed  when:  R\TC1  is  not  “N” 

Identify  the  creating  organization  POC  agency 
for  additional  information 

Range:  48  characters 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

CREATING 
ORGANIZATION 
POC  ADDRESS 

R-x\POC3 

Allowed  when:  R\TC1  is  not  “N” 

Identify  the  creating  organization  POC  address 
for  additional  information 

Range:  48  characters 

CREATING 
ORGANIZATION 
POC  TEEEPHONE 

R-x\POC4 

Allowed  when:  R\TC1  is  not  “N” 

Identify  the  creating  organization  POC 
telephone  for  additional  information. 

Range:  20  characters 

DATE  AND  TIME 
OE  COPY 

R-x\RI5 

R/R  Ch  10  Status:  RO 

Date  and  time  the  copy  was  made  using  the 
format  defined  in  Subsection  9.5.1 .  Example 
08-19-2014-17-33-59 

Allowed  when:  R\TC1  is  not  “N” 

Range:  Custom  date  and  time 

Copying  Organization  Point  of  Contact 

COPYING 
ORGANIZATION 
POC  NAME 

R-x\DPOCI 

Allowed  when:  R\TC1  is  not  “N”. 

Identify  the  copying  organization  POC  name 
for  additional  information 

Range:  24  characters 

COPYING 
ORGANIZATION 
POC  AGENCY 

R-x\DPOC2 

Allowed  when:  R\TC1  is  not  “N”. 

Identify  the  copying  organization  POC  agency 
for  additional  information. 

Range:  48  characters. 

COPYING 
ORGANIZATION 
POC  ADDRESS 

R-x\DPOC3 

Allowed  when:  R\TC1  is  not  “N”. 

Identify  the  copying  organization  POC  address 
for  additional  information. 

Range:  48  characters. 

COPYING 
ORGANIZATION 
POC  TEEEPHONE 

R-x\DPOC4 

Allowed  when:  R\TC1  is  not  “N” 

Identify  the  copying  organization  POC 
telephone  for  additional  information. 

Range:  20  characters 

POST  PROCESS 

MODIEIED 

RECORDING 

R-x\RI6 

R/R  Ch  10  Status:  R 

Indicate  modified  recording. 

Allowed  when:  R\TC1  is  not  “N” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

Y 

Yes 

N 

No 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

POST  PROCESS 

R-x\RI7 

R/R  Ch  10  Status:  RO 

Indicate  the  type  of  post-process  modification 

MODIFICATION 

Allowed  when:  R\TC1  is  not  “N” 

to  the  recording. 

TYPE 

Range:  Enumeration 

Enumeration 

Description 

1 

Time  subset 

2 

Channel  subset 

3 

Time  -  channel  subset 

4 

Channel  superset 

5 

Time  subset  -  channel  superset 

6 

Filter 

7 

Overwrite 

DATE  AND  TIME 

R-x\RI8 

R/R  Ch  10  Status: 

RO 

Date  and  time  the  modification  was  made  using 

OF 

Allowed  when:  R\TC1  is  not  “N” 

the  format  defined  in  Subsection  9.5.1. 

MODIFICATION 

Range:  Custom  date  and  time 

Example  08-19-2014-17-33-59 

Modifying  Organization  Point  of  Contact 

MODIFYING 

R-x\MPOCI 

Allowed  when:  R\TC1  is  not  “N”. 

Identify  the  modifying  organization  POC  name 

ORGANIZATION 
POC  NAME 

Range:  24  characters 

for  additional  information 

MODIFYING 

R-x\MPOC2 

Allowed  when:  R\TC1  is  not  “N”. 

Identify  the  modifying  organization  POC 

ORGANIZATION 
POC  AGENCY 

Range:  48  characters 

agency  for  additional  information. 

MODIFYING 

R-x\MPOC3 

Allowed  when:  R\TC1  is  not  “N”. 

Identify  the  modifying  organization  POC 

ORGANIZATION 
POC  ADDRESS 

Range:  48  characters 

address  for  additional  information. 

MODIFYING 

R-x\MPOC4 

Allowed  when:  R\TC1  is  not  “N” 

Identify  the  copying  organization  POC 

ORGANIZATION 
POC  TEEEPHONE 

Range:  20  characters 

telephone  for  additional  information. 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

CONTINUOUS 

RECORDING 

ENABLED 

R-x\CRE 

R/R  Ch  10  Status:  R 

Indicate  if  continuous  recording  is  enabled. 

Allowed  when:  R\TC1  is  not  “N” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

T 

True 

E 

Ealse 

RECORDER- 
REPRODUCER 
SETUP  SOURCE 

R-x\RSS 

R/R  Ch  10  Status: 

R 

Indicate  the  recorder-reproducer  setup  source. 

Allowed  when:  R\ID  is  specified 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

R 

Setup  file  on  RMM  only 

C 

Command  setup  file  only 

RP 

RMM  primary,  command 
secondary 

CP 

Command  primary,  RMM 
secondary 

RECORDER 

SERIAL  NUMBER 

R-x\RI9 

Allowed  when:  R\ID  is  specified 

Serial  number  of  the  recorder. 

Range:  64  characters 

RECORDER 

EIRMWARE 

REVISION 

R-x\RII0 

Allowed  when:  R\ID  is  specified 

Eirmware  revision  number  for  the  recorder. 

Range:  256  characters 

NUMBER  OE 
MODULES 

R-x\RIM\N 

Allowed  when:  R\ID  is  specified 

Number  of  modules  in  the  recorder. 

Range:  1-999 

MODULE  ID 

R-x\RIMI-n 

Allowed  when:  R\RIM\N  >  0 

Identify  this  module. 

Range:  64  characters 

MODULE  SERIAL 
NUMBER 

R-x\RIMS-n 

Allowed  when:  R\RIM\N  >  0 

Serial  number  of  this  module. 

Range:  64  characters 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

MODULE 

FIRMWARE 

REVISION 

R-x\RIMF-n 

Allowed  when:  R\RIM\N  >  0 

Firmware  revision  number  for  this  module. 

Range:  256  characters 

NUMBER  OF 

RMMS 

R-x\RMM\N 

Allowed  when:  R\RIM\N  >  0 

Number  of  RMMs. 

Range:  1-99 

RMM  IDENTIFIER 

R-x\RMMID-n 

Allowed  when:  R\RMM\N  >  0 

Identify  this  RMM. 

Range:  64  characters 

RMM  SERIAE 
NUMBER 

R-x\RMMS-n 

Allowed  when:  RVRMMVN  >  0 

Serial  number  of  the  RMM. 

Range:  64  characters 

RMM  FIRMWARE 
REVISION 

R-x\RMMF-n 

Allowed  when:  R\RMM\N  >  0 

Firmware  revision  number  of  the  RMM. 

Range:  256  characters 

Recorder- Reproducer  Ethernet  Interfaces 

NUMBER  OF 

ETHERNET 

INTERFACES 

R-x\EI\N 

R/R  Ch  10  Status:  RO 

Number  of  recorder-reproducer  Ethernet 
interfaces. 

Allowed  when:  R\ID  is  specified 

Range:  0-99 

ETHERNET 

INTERFACE 

NAME 

R-x\EINM-n 

R/R  Ch  10  Status:  RO 

Name  of  the  recorder-reproducer  Ethernet 
interface. 

Allowed  when:  R\EI\N  >  0 

Range:  32  characters 

PHYSICAE 

ETHERNET 

R-x\PEIN-n 

R/R  Ch  10  Status:  RO 

Number  of  the  recorder-reproducer  physical 
Ethernet  interface 

Allowed  when:  R\EI\N  >  0 

^^TERFACE 

Range:  0-99 

ETHERNET 

R-x\EIES-n 

R/R  Ch  10  Status:  RO 

Ethernet  interface  link  speed. 

INTERFACE  FINK 

Allowed  when:  R\EI\N  >  0 

SPEED 

Range:  Enumeration 

Enumeration 

Description 

r 

Enumeration 

Description 

0 

Auto  Negotiated 

1 

10Mbps 

2 

100Mbps 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 


Parameter 

Code  Name 

Usage  A 

ttributes 

Definition 

3 

IGbps 

4 

lOGbps 

ETHERNET 

R-x\EIT-n 

R/R  Ch  10  Status:  RO 

Type  of  recorder-reproducer  Ethernet  interface. 

INTEREACE  TYPE 

Allowed  when:  R\EI\N  >  0 

Range:  Enumeration 

Enumeration 

Description 

0 

Reserved 

1 

Download 

2 

Data  streaming 

3 

Download  and  Data  streaming 

4 

Control  and  status 

5 

Download  and  Control  and 

status 

6 

Data  streaming  and  Control 
and  status 

7 

Download,  Data  streaming  and 
Control  and  status 

ETHERNET 

R-x\EIIP-n 

R/R  Ch  10  Status: 

RO 

Recorder-reproducer  Ethernet  interface  IP 

INTEREACE  IP 

Allowed  when:  R\EI\N  >  0 

address:  specify  the  IP  address  in  the  form 

ADDRESS 

Range:  xxx.xxx.xxx.xxx 

“xxx.xxx.xxx.xxx”  where  each  group  of  xxx 

Einks  from:  R-x\EPE\EDEIP-n 

can  range  from  0  to  255. 

NUMBER  OE 

R-x\EIIP\N-n 

R/R  Ch  10  Status:  RO 

Number  of  Ethernet  interface  ports. 

ETHERNET 

Allowed  when:  R\EI\N  >  0 

INTEREACE 

PORTS 

Range:  0-99 

PORT  ADDRESS 

R-x\EEPA-n-m 

R/R  Ch  10  Status:  RO 

Recorder-reproducer  Ethernet  interface  IP  port 

Allowed  when:  R\EI\N  >  0 

address:  specify  the  IP  address  in  the  form 

Range:  0-65535 

“xxxxx”  where  xxxxx  can  range  from  0  to 

Einks  from:  R-x\EPE\EDEPA-n 

65535  lAW  ITE. 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

PORT  TYPE 

R-x\EEPT-n-m 

R/R  Ch  10  Status:  RO 

Recorder-reproducer  Ethernet  interface  IP  port 

Allowed  when:  R\EI\N  >  0 

type. 

Range:  Enumeration 

Enumeration 

Description 

0 

Reserved 

1 

Download 

2 

Data  streaming 

4 

Control  and  status 

X 

Sum  values  for  multiple  type 

Recorder-Reproducer  Channel  Group  Streams 

NUMBER  OE 

R-x\CG\N 

R/R  Ch  10  Status:  RO 

Number  of  recorder-reproducer  channel  group 

CHANNEE 

Allowed  when:  R\ID  specified 

streams. 

GROUPS 

Range:  0-99 

CHANNEE  GROUP 

R-x\CGNM-n 

R/R  Ch  10  Status:  RO 

Name  of  the  recorder-reproducer  channel 

NAME 

Allowed  when:  R\CG\N  >  0 

group.  Eirst  character  must  be  alphabetic. 

Range:  32  characters 

Einks  from:  R-x\OSNM-n,  R-x\EPE\ESNM-n 

CHANNEE  GROUP 

R-x\CGSN-n 

R/R  Ch  10  Status:  RO 

Specify  the  channel  group  stream  as  an  integer 

STREAM 

Allowed  when:  R\CG\N  >  0 

number. 

NUMBER 

Range:  1-99 

Einks  from:  R-x\EPE\ESSN-n 

NUMBER  OE 

R-x\CGCH\N-n 

R/R  Ch  10  Status:  RO 

Number  of  channels  in  the  channel  group 

GROUP 

Allowed  when:  R\CG\N  >  0 

stream. 

CHANNEES 

Range:  1-65536 

GROUP  CHANNEE 

R-x\CGCN-n-m 

R/R  Ch  10  Status:  RO 

Specify  the  channel  ID,  from  R-x\TKl-n. 

NUMBER 

Allowed  when:  R\CG\N  >  0 

Range:  0-65535 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Recorder-Reproducer  Drives  and  Volumes 

NUMBER  OF 
DRIVES 

R-x\DR\N 

R/R  Ch  10  Status:  RO 

Number  of  recorder-reproducer  drives  (stream 
destinations).  Default  is  “1”. 

Allowed  when:  R\ID  is  specified 

Range:  0-9999 

DRIVE  NAME 

R-x\DRNM-n 

R/R  Ch  10  Status:  RO 

Name  of  the  recorder-reproducer  drive.  First 
character  must  be  alphabetic. 

Allowed  when:  R\DR\N  >  0 

Range:  32  characters 

DRIVE  NUMBER 

R-x\DRN-n 

R/R  Ch  10  Status:  RO 

Specify  the  drive  as  an  integer  number. 

Allowed  when:  R\DR\N  >  0 

Range:  1-9999 

DRIVE  BEOCK 

SIZE 

R-x\DRBS-n 

R/R  Ch  10  Status:  RO 

Specify  the  drive  bytes  per  block  size. 

Allowed  when:  R\DR\N  >  0 

Range:  1-99999999 

NUMBER  OF 

DRIVE  VOEUMES 

R-x\DRVE\N-n 

R/R  Ch  10  Status:  RO 

Number  of  volumes  in  the  drive.  Default  is 

tt 

Allowed  when:  R\DR\N  >  0 

Range:  1-9999 

VOEUME  NAME 

R-xWENM-n-m 

R/R  Ch  10  Status:  RO 

Name  of  the  drive  volume.  First  character  must 
be  alphabetic. 

Allowed  when:  R\DR\N  >  0 

Range:  32  characters 

VOEUME 

NUMBER 

R-xWEN-n-m 

R/R  Ch  10  Status:  RO 

Specify  the  volume  as  an  integer  number. 

Allowed  when:  R\DR\N  >  0 

Range:  Integer,  1-9999 

VOEUME 

BEOCKS  TO 
AEEOCATE 

R-xWEBA-n-m 

R/R  Ch  10  Status:  RO 

Specify  how  volume  blocks  will  be  allocated. 

Allowed  when:  R\DR\N  >  0 

Range:  Enumeration 

Enumeration 

Description 

0 

All 

1 

Available 

2 

Number  of  blocks 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

VOLUME 

NUMBER  OE 
BEOCKS 

R-xWLNB-n-m 

R/R  Ch  10  Status:  RO 

Specify  the  volume  as  an  integer  number  of 
blocks. 

Allowed  when:  R\DR\N  >  0 

Range:  max  32  digits 

Recorder-Reproducer  Stream/Drive-Volume  Links 

NUMBER  OE 

EINKS 

R-x\L\N 

R/R  Ch  10  Status:  RO 

Number  of  recorder-reproducer  channel  group 
streams/drive- volume  links. 

Allowed  when:  R\ID  is  specified 

Range:  0-99 

EINK  NAME 

R-x\LNM-n 

R/R  Ch  10  Status:  RO 

Name  of  the  recorder-reproducer  channel  group 
stream/drive- volume  link.  Eirst  character  must 
be  alphabetic. 

Allowed  when:  R\E\N  >  0 

Range:  32  characters 

EINK  SOURCE 
STREAM  NAME 

R-x\LSNM-n 

R/R  Ch  10  Status:  RO 

Specify  the  recorder-reproducer  channel  group 
stream  name. 

Allowed  when:  R\L\N  >  0 

Range:  32  characters 

EINK  SOURCE 
STREAM 

NUMBER 

R-x\LSSN-n 

R/R  Ch  10  Status:  RO 

Specify  the  recorder-reproducer  channel  group 
stream/drive-volume  number,  from  R-x\CGSN- 

n. 

Allowed  when:  R\E\N  >  0 

Range:  Integer,  1-99 

EINK 

DESTINATION 
DRIVE  NUMBER 

R-x\LDDN-n 

R/R  Ch  10  Status:  RO 

Specify  the  recorder-reproducer  channel  group 
stream  destination  drive  number,  from 
R-x\DRN-n. 

Allowed  when:  R\L\N  >  0 

Range:  Integer,  1-9999 

EINK 

DESTINATION 

VOLUME 

NUMBER 

R-x\LDVN-n 

R/R  Ch  10  Status:  RO 

Specify  the  recorder-reproducer  channel  group 
stream  destination  volume  number,  from  R- 
xWEN-n-m. 

Allowed  when:  R\E\N  >  0 

Range:  Integer,  1-9999 

.ecorder- Reproducer  Ethernet  Interface  Publishing  Links 

'  NUMBER  OE 
ETHERNET 
PUBEISHING 

EINKS 

R-x\EPE\N 

R/R  Ch  10  Status:  RO 

Number  of  Stream/Ethernet  Interface  Publish 
Einks 

Allowed  when:  R\ID  is  specified 

Range:  0-99 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

ETHERNET 

PUBEISHING 

EINK  NAME 

R-x\EPE\ENM-n 

R/R  Ch  10  Status:  RO 

Name  of  Stream/Ethernet  Interface  Publish 

Einks 

Allowed  when:  R\EPE\N  >  0 

Range:  32  characters 

EINK  SOURCE 
STREAM  NAME 

R-x\EPE\ESNM-n 

R/R  Ch  10  Status:  RO 

The  Channel  Group  Stream  Name  to  link  this 
Ethernet  Publishing  Interface. 

Allowed  when:  R\EPE\N  >  0 

Range:  32  characters 

Einks  to:  R-x\CGNM-n 

EINK  SOURCE 
STREAM 

NUMBER 

R-x\EPE\ESSN-n 

R/R  Ch  10  Status:  RO 

The  Channel  Group  Stream  Number  to  link  this 
Ethernet  Publishing  Interface  from  R-X\CGSN. 

Allowed  when:  R\EPE\N  >  0 

Range  =  0-99 

Einks  to:  R-x\CGSN-n 

EINK 

DESTINATION 
ETHERNET 
INTEREACE  IP 
ADRESS 

R-x\EPE\EDEIP-n 

R/R  Ch  10  Status:  RO 

The  Destination  Ethernet  interface  IP  address 
for  this  link. 

Allowed  when:  R\EPE\N  >  0 

Range:  xxx.xxx.xxx.xxx 

Einks  to:  R-x\EIIP-n 

EINK 

DESTINATION 
ETHERNET 
INTEREACE  PORT 
ADDRESS 

R-x\EPE\EDEPA- 

n 

R/R  Ch  10  Status:  RO 

The  Destination  Ethernet  interface  port  address 
for  this  link. 

Allowed  when:  R\EPE\N  >  0 

Range:  0-65535 

Einks  to:  R-x\EI\PA 

Computer- Generated  Data  Packet,  User-Defined  Dei 

inition 

USER-DEEINED 
CHANNEE  ID 

R-x\UD\TKI 

R/R  Ch  10  Status:  RO 

Specify  the  channel  ID  for  computer-generated 
user-defined  packets. 

Allowed  when:  R\ID  is  specified 

Range:  1-65535 

Recording  Event  Definitions 

RECORDING 

EVENTS 

ENABEED 

R-x\EV\E 

R/R  Ch  10  Status:  RO 

Indicate  if  events  are  enabled.  Events  must  be 
enabled  to  generate  event  packets. 

Allowed  when:  R\ID  is  specified 

Range:  Enumeration 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

Enumeration 

Description 

T 

True 

E 

Ealse 

Default:  E 

RECORDING 

R-x\EV\TKI 

R/R  Ch  10  Status:  RO 

Specify  the  channel  ID  for  recording  event 

EVENTS 

Allowed  when:  R\EV\E  =  “T” 

packets. 

CHANNEE  ID 

Required  when:  Allowed 

Range:  1-65535 

NUMBER  OE 

R-x\EV\N 

R/R  Ch  10  Status:  RO 

Specify  the  number  of  individual  recording 

RECORDING 

Allowed  when:  R\EV\E  =  “T” 

event  types. 

EVENTS 

Required  when:  Allowed 

Range:  1-999 

RECORDER 

R-x\EV\IEE 

R/R  Ch  10  Status:  RO 

Indicate  if  recorder  internal  events  are  enabled. 

INTERNAE 

Allowed  when:  R\EV\E  =  “T” 

EVENTS 

Required  when:  Allowed 

ENABEED 

Range:  Enumeration 

Enumeration 

Description 

T 

True 

E 

Ealse 

Recording  Event 

EVENT  ID 

R-x\EV\ID-n 

R/R  Ch  10  Status:  RO 

Identify  the  name  of  the  individual  recording 

Allowed  when:  R\EV\N  >  0 

event. 

Range:  32  characters 

EVENT 

R-x\EV\D-n 

R/R  Ch  10  Status:  RO 

Identify  the  description  of  the  event. 

DESCRIPTION 

Allowed  when:  R\EV\N  >  0 

Range:  256  characters 

EVENT  DATA 

R-x\EV\EDP-n 

Allowed  when:  R\EV\N  >  0 

Indicate  if  event  data  processing  is  enabled. 

PROCESSING 

Range:  Enumeration 

ENABEED 

Enumeration 

Description 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

T 

True 

E 

Ealse 

EVENT  TYPE 

R-x\EV\T-n 

R/R  Ch  10  Status: 

RO 

Indicate  the  recording  event  type. 

Allowed  when:  R\EV\N  >  0 

Range:  Enumeration 

Enumeration 

Description 

E 

External 

D 

Measurement  discrete 

E 

Measurement  limit 

R 

Recorder 

0 

Other 

Default:  R 

EVENT  PRIORITY 

R-x\EV\P-n 

R/R  Ch  10  Status:  RO 

Indicate  the  recording  event  priority. 

Allowed  when:  R\EV\N  >  0 

Range:  Enumeration 

Enumeration 

Description 

1 

Priority  1 

2 

Priority  2 

3 

Priority  3 

4 

Priority  4 

5 

Priority  5 

EVENT  CAPTURE 

R-x\EV\CM-n 

R/R  Ch  10  Status: 

RO 

Indicate  the  recording  event  capture  mode. 

MODE 

Allowed  when:  R\EV\N  >  0 

Range:  Enumeration 

Enumeration 

Description 

1 

Mode  1 

2 

Mode  2 

3 

Mode  3 

4 

Mode  4 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

5 

Mode  5 

6 

Mode  6 

7 

Mode  7 

EVENT  INITIAE 
CAPTURE 

R-x\EV\IC-n 

R/R  Ch  10  Status: 

RO 

Indicate  if  initial  capture  of  event  is  enabled. 

Allowed  when:  R\EV\N  >  0 

Range:  Enumeration 

Enumeration 

Description 

T 

True 

E 

Ealse 

RECORDING 
EVENT  EIMIT 
COUNT 

R-x\EV\EC-n 

R/R  Ch  10  Status: 

RO 

Specify  the  limit  count  for  the  individual 
recording  event. 

Allowed  when:  R\EV\N  >  0 

Range:  1-99999999 

EVENT  TRIGGER 

MEASUREMENT 

SOURCE 

R-x\EV\MS-n 

R/R  Ch  10  Status:  RO 

Identify  the  data  link  name  consistent  with  the 
mux/mod  group  that  contains  the  event  trigger 
measurement  if  event  type  is  “D”  or  “E”. 

Allowed  when:  R\EV\N  >  0 

Range:  32  characters 

EVENT  TRIGGER 

MEASUREMENT 

NAME 

R-x\EV\MN-n 

R/R  Ch  10  Status:  RO 

Identify  the  event  trigger  measurand  name  if 
the  event  type  is  “D”  or  “E”. 

Allowed  when:  R\EV\N  >  0 

Range:  32  characters 

EVENT 
PROCESSING 
MEASUREMENT 
DATA  EINK 

NAME 

R-x\EV\DEN-n 

Allowed  when:  R\EV\N  >  0 

Identify  the  data  link  name  consistent  with  the 
PCM  format  and  PCM  measurement  groups, 
bus  data  group,  or  message  data  group  that 
contains  the  measurements  to  be  processed. 

Einks  to:  P-d\DEN,  B-x\DEN,  S-d\DEN 

Range:  32  characters 

NUMBER  OE 
MEASUREMENTS 
TO  PROCESS 

R-x\EV\PM\N-n 

Allowed  when:  R\EV\N  >  0 

Specify  the  number  of  measurements  to  process 
for  this  event. 

Range:  0-9999 

MEASUREMENT 
NAME  TO 

PROCESS 

R-x\EV\PM\MN- 

n-m 

Allowed  when:  R\EV\PM\N  >  0 

Identify  the  measurement  name  to  be  processed 
for  the  event. 

Einks  to:  B-x\MN-i-n-p,  D-x\MN-y-n,  S-d\MN-i-n- 
P 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

Range:  32  characters 

PRE-EVENT 

PROCESSING 

DURATION 

R-x\EV\PM\PRE- 

n-m 

Allowed  when:  R\EV\PM\N  >  0 

Specify  the  number  of  seconds  the 
measurement  will  be  processed  before  the  event 
time. 

Range:  0-9999 

POST-EVENT 

PROCESSING 

DURATION 

R-x\EV\PM\PST- 

n-m 

Allowed  when:  R\EV\PM\N  >  0 

Specify  the  number  of  seconds  the 
measurement  will  be  processed  after  the  event 
time. 

Range:  0-9999 

Recording  Index 

RECORDING 

INDEX  ENABEED 

R-x\IDX\E 

R/R  Ch  10  Status:  RO 

Indicate  if  index  is  enabled.  Index  must  be 
enabled  to  generate  index  packets. 

Allowed  when:  R\ID  is  specified 

Range:  Enumeration 

Enumeration 

Description 

T 

True 

E 

Ealse 

RECORDING 

INDEX  CHANNEE 
ID 

R-x\IDX\TKI 

R/R  Ch  10  Status: 

RO 

Specify  the  channel  ID  for  recording  index 
packets. 

Allowed  when:  R\IDX\E  =  “T” 

Required  when:  Allowed 

Range:  1  -  65535 

RECORDING 

INDEX  TYPE 

R-xMDXMT 

R/R  Ch  10  Status:  RO 

Specify  index  type  for  recording  index  packets. 

Allowed  when:  R\IDX\E  =  “T” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

T 

Time 

C 

Count 

Time  Index  Type  Attribute 

INDEX  TIME 
VAEUE 

R-MDXMTV 

R/R  Ch  10  Status:  RO 

Identify  the  number  of  microseconds  for  each 
index  entry  generation. 

Allowed  when:  R\IDX\E  =  “T” 

Range:  0-99999999 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

Count  Index  Type  Attribute 

INDEX  COUNT 
VALUE 

R-MDXMCV 

R/R  Ch  10  Status:  RO 

Identify  the  number  of  packets  for  each  index 
entry  generation. 

Allowed  when:  R\IDX\E  =  “T” 

Range:  0-9999 

MIL-STD-1553  Recorder  Control 

MESSAGE 

MONITOR 

RECORD 

CONTROL 

ENABLED 

R-x\MRC\E 

Allowed  when:  R\ID  is  specified 

Indicate  if  message  monitor  record  control  is 
enabled. 

Range:  Enumeration 

Enumeration 

Description 

T 

True 

E 

Ealse 

CHANNEL  ID 
NUMBER 

R-x\MRC\ID 

Allowed  when:  R\MRC\E  =  “T” 

Specify  the  MIL-STD-1553  channel  ID  that 
contains  the  record  control  message. 

Range:  1-65535 

MESSAGE 

RECORD 

CONTROL  TYPE 

R-x\MRC\RCT 

Allowed  when:  R\MRC\E  =  “T” 

Specify  the  MIL-STD-1553  message  monitor 
record  control  type. 

Range:  Enumeration 

Enumeration 

Description 

0 

Stop-start 

1 

Pause-resume 

STOP-PAUSE 

COMMAND 

WORD 

R-x\MRC\SPM 

Allowed  when:  R\MRC\E  =  “T” 

Specify  the  command  word  of  the  MIL-STD- 
1553  message  to  be  used  for  stop-pause. 

Range:  Hexadecimal,  0000-EEEE 

START-RESUME 

COMMAND 

WORD 

R-x\MRC\SRM 

Allowed  when:  R\MRC\E  =  “T” 

Specify  the  command  word  of  the  MIL-STD- 
1553  message  to  be  used  for  start-resume. 

Range:  Hexadecimal,  0000-EEEE 

Data 

NOTE:  Define  information  contained  on  each  track  of  the  tape  or  each  channel  of  the  storage  media. 

TRACK  NUMBER/ 
CHANNEL  ID 

R-x\TKl-n 

R/R  Ch  10  Status:  R 

Specify  the  track  number  or  the  channel  ID  that 
contains  the  data  to  be  specified. 

Allowed  when:  R\N  >  0 

Required  when:  Allowed 

Range:  1-65535 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

RECORDING 

R-x\TK2-n 

Allowed  when:  R\N  >  0 

Specify  the  recording  technique  used  for  this 

TECHNIQUE 

Range:  Enumeration 

track. 

Enumeration 

Description 

EM/EM 

Indirect  EM 

HDDR 

Hard  Disk  Recording 

PRE_D 

Pre-detection 

DIRECT 

Direct  PM 

EMWBI 

PM-Wide  Band  GRP  I 

EMWBII 

PM-Wide  Band  GRP  II 

EM-IM 

PM-Intermediate  Band 

EM-NB 

PM-Narrow  Band 

DOUDEN 

Double  Density 

RO-K 

(Rotary  [Single  Track]) 

RO-MUX 

(Rotary  [Multiplexed]) 

SSR 

Solid  State 

OTHER 

All  other  techniques 

INPUT  STREAM 

R-xMDDR-n 

Allowed  when:  R\N  >  0 

Specify  how  input  stream  is  recorded.  Stream 

DE- 

Range:  Enumeration 

is  recorded  after  being  derandomized. 

RANDOMIZATIO 

Enumeration 

Description 

Stream  is  recorded  as  received.  If  PCM  data 

N 

Y 

Yes 

type  is  not  throughput  and  input  data  stream  is 

N 

No 

randomized,  this  parameter  must  be  “Y”. 

Default:  N 

DATA  SOURCE  ID 

R-x\DSI-n 

R/R  Ch  10  Status:  R 

Specify  the  data  source  identification.  Por  a 

Allowed  when:  R\N  >  0 

site-recorded  multiplexed  track,  provide  a  data 

Einks  from:  G\DSTn 

source  identification. 

Einks  to:  M-x\ID 

Required  when:  Allowed 

Range:  32  characters 

DATA  DIRECTION 

R-x\TK3-n 

Allowed  when:  R\N  >  0 

Specify  data  direction. 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

Range:  Enumeration 

Enumeration 

Description 

EWD 

Eorward 

REV 

Reverse 

Default:  EWD 

RECORDER 

R-x\TK4-n 

R/R  Ch  10  Status:  R 

Specify  the  recorder  physical  channel  for  the 

PHYSICAE 

Allowed  when:  R\N  >  0 

channel  ID  (TKI). 

CHANNEE 

Required  when:  Allowed 

NUMBER 

Range:  1-65535 

CHANNEE 

R-x\CHE-n 

R/R  Ch  10  Status:  R 

Indicate  if  source  is  enabled.  Source  must  be 

ENABEE 

Allowed  when:  R\N  >  0 

enabled  to  generate  data  packets. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

T 

True 

E 

Ealse 

CHANNEE  DATA 

R-x\CDT-n 

R/R  Ch  10  Status: 

R 

Specify  the  type  of  source  if  “STO”  was 

TYPE 

Allowed  when:  R\N  >  0 

specified  in  G  group  data  source  type. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

PCMIN 

PCM  Input 

VIDIN 

Video  Input 

ANAIN 

Analog  Input 

1553IN 

1553  Input 

DISIN 

Discrete  Input 

TIMEIN 

IRIG  Time  Input 

UARTIN 

UART  Input 

429IN 

ARINC  429  Input 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

MSGIN 

Message  Data  Input 

IMGIN 

Image  Data  Input 

1394IN 

IEEE- 1394  Input 

PARIN 

Parallel  Input 

ETHIN 

Ethernet  Input 

TSPIIN 

TSPECTS  Input 

CANIN 

CAN  bus  Input 

EBCHIN 

Eibre  Channel  Input 

TMOUT 

Telemetry  Output 

CHANNEL  DATA 
LINK  NAME 

R-x\CDLN-n 

R/R  Ch  10  Status: 

R 

Identify  the  data  link  name  consistent  with  the 
PCM  format,  bus  data,  or  message  data  group 
for  the  channel. 

Allowed  when:  RVN  >  0 

Required  when:  A  data  link  is  assoeiated  with  the 
ehannel. 

Links  to:  P-d\DLN,  B-x\DLN,  S-d\DLN 

Range:  32  eharacters 

SECONDARY 
HEADER  TIME 
EORMAT 

R-x\SHTE-n 

R/R  Ch  10  Status:  RO 

If  enabled,  the  secondary  header  time  format. 

Allowed  when:  R\N  >  0 

Range:  Enumeration 

Enumeration 

Deseription 

0 

Chanter  4  BCD 

1 

IEEE-1588 

2 

ERTC 

Data  Type  Attributes 

PCM  Data  Type  Attributes 

PCM  DATA  TYPE 
EORMAT 

R-x\PDTE-n 

R/R  Ch  10  Status:  RO 

PCM  data  type  format.  Enumeration  equates  to 
format  number  in  Chanter  10. 

Allowed  when:  R\CDT  is  “PCMIN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 
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Parameter 


Code  Name 


Usage  Attributes 


Definition 


reserved 


Chapter  4,  Chapter  7,  Chapter 
8 


DATA  PACKING 
OPTION 


R-x\PDP-n 


R/R  Ch  10  Status:  RO 


How  data  is  placed  in  the  packets. 


Allowed  when:  R\CDT  is  “PCMIN” 


Required  when:  Allowed 


Range:  Enumeration 


Enumeration 


UN 


TM 


PFS 


Description 


Unpacked 


Throughput  mode 


Packed  with  frame  sync 


RECORDER 
POEARITY 
:TTING 


R-x\RPS-n 


R/R  Ch  10  Status:  RO 


Allowed  when:  P-d\CDT  is  “PCMIN’ 


Range:  Enumeration 


Recorder  Data  polarity  setting.  Specify  if  the 
recorder  is  to  invert  the  input  stream  before 
recording  it. 


Enumeration 


N 


I 


Description 


Normal  -  Do  not  invert  data 
prior  to  recording 


Invert  data  prior  to  recording 


Default:  N 


INPUT  CEOCK 
EDGE 


R-xMCE-n 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\CDT  is  “PCMIN” 


Specify  the  input  clock  edge  relative  to  the  data 
in  degrees. 


Range:  Enumeration 


Enumeration 


180 


Description 


0  degrees 


180  degrees 


Default:  0 


INPUT  SIGNAE 
TYPE 


R-xMST-n 


R/R  Ch  10  Status:  RO 


Type  of  input  signal. 


Allowed  when:  R\CDT  is  “PCMIN’ 


Range:  Enumeration 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Enumeration 

Description 

SE 

Single  ended 

DIEE 

Differential 

RS422 

RS-422  standard  differential 

TTL 

Single  ended  with  TTL 

Default:  DIEE 

INPUT 

R-xMTH-n 

R/R  Ch  10  Status:  RO 

Specify  the  input  threshold  level  for  selectable 

THRESHOLD 

Allowed  when:  R\CDT  is  “PCMIN” 

electrical  interface.  The  value  is  the  threshold 

Required  when:  Allowed 

level  in  volts. 

Range:  -999.9  to  999.9 

INPUT 

R-xMTM-n 

R/R  Ch  10  Status:  RO 

Specify  the  input  termination. 

TERMINATION 

Allowed  when:  R\CDT  is  “PCMIN” 

Range:  Enumeration 

Enumeration 

Description 

LOW-Z 

Low  impedance 

HIGH-Z 

High  impedance 

PCM  VIDEO  TYPE 

R-x\PTE-n 

R/R  Ch  10  Status: 

RO 

Compression  technique  for  video  recorded  as 

EORMAT 

Allowed  when:  R\CDT  is  “PCMIN” 

standard  Chapter  4  PCM.  The  compressed  data 

Range:  Enumeration 

is  encapsulated  in  ISO  Standard  Transport 

Enumeration 

Description 

Stream  (TS)  frames.  If  type  format  is 

NONE 

Not  video 

“OTHER”,  then  a  vendor  spec  is  required  to 

MPEGl 

MPEGl  Compression 

identify  the  data  compression  technique. 

MPEG2 

MPEG2  Compression 

Specify  “NONE”  if  data  is  not  video  data. 

H261 

H.261  Compression 

WAVE 

Wavelet  Compression 

OTHER 

Other  Compression  (including 
uncompressed) 

Default:  NONE 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

PCM  RECORDER- 
REPRODUCER 
MINOR  ERAME 
EIETERING 
ENABEED 

R-x\MEE\E-n 

R/R  Ch  10  Status:  RO 

Indicate  if  recorder-reproducer  minor  frame 
filtering  is  enabled  for  the  PCM  channel  (not 
applicable  for  throughput  mode  PCM 
channels). 

Allowed  when:  R\PDP  =  “PES”  or  “UN” 

Range:  Enumeration 

Enumeration 

Description 

T 

True 

E 

Ealse 

PCM  POST¬ 
PROCESS 
OVERWRITE  AND 
EIETERING 
ENABEED 

R-x\POE\E-n 

R/R  Ch  10  Status: 

RO 

Indicate  if  post-process  overwrite  and  filtering 
is  enabled  for  the  PCM  channel. 

Allowed  when:  R\PDP  =  “PES”  or  “UN” 

Range:  Enumeration 

Enumeration 

Description 

T 

True 

E 

Ealse 

PCM  POST¬ 
PROCESS 
OVERWRITE  AND 
EIETERING  TYPE 

R-x\POE\T-n 

R/R  Ch  10  Status: 

RO 

Indicate  the  type  of  post-process  overwrite  and 
filtering  for  the  PCM  channel. 

Allowed  when:  R\POE\E  =  “T” 

Range:  Enumeration 

Enumeration 

Description 

ME 

Minor  frame 

SM 

Selected  measurement 

B 

Both 

MINOR  ERAME 
EIETERING 
DEEINITION  TYPE 

R-x\MEE\EDT-n 

R/R  Ch  10  Status: 

RO-PAK 

Specify  the  PCM  minor  frame  filtering 
definition  type. 

Allowed  when:  R\POE\T  is  “B”  or  “ME”  or 
R\MEE\E  is  “T” 

Range:  Enumeration 

Enumeration 

Description 

IN 

Inclusive  filtering 

EX 

Exclusive  filtering 
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Parameter 


Code  Name 


Usage  Attributes 


Definition 


NUMBER  OF 
MINOR  FRAME 
FIFTERING 
DEFINITIONS 


R-x\MFF\N-n 


R/R  Ch  10  Status:  RO-PAK 


Allowed  when:  R\POF\T  is  “B”  or  “MF”  or 
R\MFF\E  is  “T” 


Specify  the  number  of  PCM  minor  frame 
filtering  definitions. 


Range:  0-999 


FIFTERED  MINOR 
FRAME  NUMBER 


R-x\MFF\MFN-n- 

m 


R/R  Ch  10  Status:  RO-PAK 


Allowed  when:  R\MFF\N  >  0 


Specify  the  PCM  minor  frame  number  to  be 
filtered. 


Required  when:  Allowed 


Range:  0-999 


NOTE;  For  PCM  formats  with  multiple  subframe  ID  counters,  all  minor  frame  numbers  defined  for  filtering  are  associated  with  the  first  subframe 
ID  counter. 


NUMBER  OF 

SEFECTED 

MEASUREMENT 

OVERWRITE 

DEFINITIONS 


R-x\SMF\N-n 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\POF\T  is  “B”  or  “SM”  or 
R\MFF\E  is  “T” 


Range:  0-99 


Specify  the  number  of  PCM  selected 
measurement  overwrite  definitions. 


SEFECTED 

MEASUREMENT 

NAME 


R-x\SMF\SMN-n- 

m 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\SMF\N  >  0 


Specify  the  PCM  selected  measurement  name 
to  be  overwritten. 


Required  when:  Allowed 


Finks  to:  D-x\MN-y-n 


Range:  32  characters 


MEASUREMENT 
OVERWRITE  TAG 


R-x\SMF\MFOT- 

n-m 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\SMF\N  >  0 


Indicate  if  the  PCM  measurement  is  tagged  for 
overwriting. 


Range:  Enumeration 


Enumeration 


O 


N 


Description 


Overwrite 


No  overwriting 


Default:  N 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

MIL-STD-1553  Bus  Data  Type  Attributes 

MIL-STD-1553 

BUS  DATA  TYPE 
FORMAT 

R-x\BTF-n 

R/R  Ch  10  Status:  RO 

MIL-STD-1553  bus  data  type  format. 
Enumeration  equates  to  format  number  in 
Chanter  10. 

Allowed  when:  R\CDT  is  ‘T553IN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

reserved 

1 

MIL-STD-1553B  data 

2 

16PP194  bus 

MIL-STD-1553 

RECORDER- 

REPRODUCER 

FILTERING 

ENABLED 

R-x\MRF\E-n 

R/R  Ch  10  Status: 

RO 

Indicate  if  recorder-reproducer  filtering  is 
enabled  for  the  MIL-STD-1553  channel. 

Allowed  when:  R\CDT  is  ‘T553IN” 

Range:  Enumeration 

Enumeration 

Description 

T 

True 

F 

False 

MIL-STD-1553 
POST-PROCESS 
OVERWRITE  AND 
FILTERING 
ENABLED 

R-x\MOF\T-n 

R/R  Ch  10  Status: 

RO 

Indicate  if  post-process  overwrite  and  filtering 
is  enabled  for  the  MIL-STD-1553  channel. 

Allowed  when:  R\CDT  is  ‘T553IN” 

Range:  Enumeration 

Enumeration 

Description 

T 

True 

F 

False 

MIL-STD-1553 
MESSAGE 
FILTERING 
DEFINITION  TYPE 

R-x\MFD\FDT-n 

Allowed  when:  R\MRF\E  or  R\MOF\T  is  “T” 

Specify  the  message  filtering  definition  type. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

IN 

Inclusive  filtering 

EX 

Exclusive  filtering 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

NUMBER  OF 

R-x\MFD\N-n 

Allowed  when:  R\MRF\E  or  R\MOF\T  is  “T” 

Specify  the  number  of  message  filtering 

MESSAGE 

Required  when:  Allowed 

definitions. 

FIETERING 

DEFINITIONS 

Range:  0-99 

MESSAGE 

R-x\MFD\MID-n- 

Allowed  when:  R\MFD\N  >  0 

Specify  the  message  number  to  be  filtered  and 

NUMBER 

m 

Required  when:  Allowed 

overwritten. 

Range:  1-999999999 

MESSAGE  TYPE 

R-x\MFD\MT-n-m 

Allowed  when:  R\MFD\N  >  0 

Specify  the  message  type. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

RTRT 

RT/RT 

RTBC 

RT/BC 

BCRT 

BC/RT 

MC 

Mode  code 

COMMAND 

R-x\CWE-n-m 

Allowed  when:  R\MFD\N  >  0 

Method  used  to  specify  the  command  word. 

WORD  ENTRY 

Range:  Enumeration 

Enumeration 

Description 

W 

Enter  the  entire  command  word 
in  the  “COMMAND  WORD” 
attribute. 

F 

Enter  the  command  word  fields 
separately  in  the  “REMOTE 
TERMINAE  ADDRESS”, 
“SUBTERMINAE 

ADDRESS”,  “TRANSMIT/ 
RECEIVE  MODE”,  and 
“DATA  WORD  COUNT/ 
MODE  CODE”  attributes. 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Default:  E 

COMMAND 

WORD 

R-x\CMD-n-m 

Allowed  when:  R\MED\N  >  0 

Specify  the  entire  command  word  for  this 
message. 

Required  when:  RVRCWE  is  “W” 

Range:  Hexadeeimal,  0000-EEEE 

REMOTE 

TERMINAE 

ADDRESS 

R-x\MED\TRA-n- 

m 

Allowed  when:  RVMEDVN  >  0 

Specify  the  five-bit  remote  terminal  address  for 
this  message.  Use  “X”  to  indicate  a  “don’t 
care”  value. 

Required  when:  R\CWE  is  “E” 

Range:  Binary  00000-11  111 

TRANSMIT/ 
RECEIVE  MODE 

R-x\MED\TRM-n- 

m 

Allowed  when:  RVMEDVN  >  0 

Indicate  if  this  command  word  is  a  transmit  or 
receive  command.  Eor  RT/RT,  specify 
transmit. 

Required  when:  R\CWE  is  “E” 

Range:  Enumeration 

Enumeration 

Description 

1 

Transmit 

0 

Receive 

SUBTERMINAE 

ADDRESS 

R-x\MED\STA-n- 

m 

Allowed  when:  RVMEDVN  >  0 

Specify  the  five-bit  subterminal  address  for  this 
message.  Use  “X”  to  indicate  a  “don’t  care” 
value. 

Required  when:  R\CWE  is  “E” 

Range:  Binary  00000-11  111 

DATA  WORD 

COUNT/MODE 

CODE 

R-x\MED\DWC- 

n-m 

Allowed  when:  R\MED\N  >  0 

Enter  the  number  of  data  words  as  a  binary 
string,  using  “X”  to  indicate  a  “don’t  care” 
value.  If  the  subterminal  address  indicates  a 
mode  code,  enter  the  mode  code  value  as  a 
binary  string. 

Required  when:  R\CWE  is  “E” 

Range:  Binary  00000-11  111 

RECEIVE 

COMMAND 

WORD  ENTRY 

GF 

R-x\RCWE-n-m 

Allowed  when:  RVMEDVN  >  0 

Method  used  to  specify  the  receive  command 
word. 

Range:  Enumeration 

Enumeration 

Description 

W 

Enter  the  entire  command  word 
in  the  “RECEIVE 

COMMAND  WORD” 
attribute. 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

E 

Enter  the  command  word  fields 
separately  in  the  “RT/RT 
REMOTE  TERMINAE 
ADDRESS”,  “RT/RT 
SUBTERMINAE  ADDRESS”, 
and  “RT/RT  DATA  WORD 
COUNT”  attributes. 

Default:  E 

RECEIVE 

COMMAND 

WORD 

R-x\RCMD-n-m 

Allowed  when:  R\MED\N  >  0 

Specify  the  entire  receive  command  word  for 
this  RT/RT  message. 

Required  when:  RVRCWE  is  “W” 

Range:  Hexadecimal,  0000-EEEE 

RT/RT  REMOTE 

TERMINAE 

ADDRESS 

R-x\MED\RTRA- 

n-m 

Allowed  when:  R\MED\N  >  0 

Specify  the  five-bit  remote  terminal  address  for 
this  RT/RT  message.  Use  “X”  to  indicate  a 
“don’t  care”  value. 

Required  when:  RVRCWE  is  “E” 

Range:  Binary,  00000  -  11111 

RT/RT 

SUBTERMINAE 

ADDRESS 

R-x\MED\RSTA- 

n-m 

Allowed  when:  RVMEDVN  >  0 

Specify  the  five-bit  subterminal  address  for  this 
RT/RT  message.  Use  “X”  to  indicate  a  “don’t 
care”  value. 

Required  when:  RVRCWE  is  “E” 

Range:  Binary  00000  -  11111 

RT/RT  DATA 

WORD  COUNT 

R-x\MED\RDWC- 

n-m 

Allowed  when:  RVMEDVN  >  0 

Enter  the  number  of  data  words  as  a  binary 
string,  using  “X”  to  indicate  a  “don’t  care” 
value.  Exclude  status  and  time  words  (an 

RT/RT  message  cannot  contain  a  mode  code). 

Required  when:  RVRCWE  is  “E” 

Range:  Binary  00000  -  11111 

NUMBER  OE 

SEEECTED 

MEASUREMENT 

OVERWRITE 

DEEINITIONS 

R-x\BME\N-n 

R/R  Ch  10  Status:  RO 

Specify  the  number  of  bus  measurement 
overwrite  definitions. 

Allowed  when:  RVMREVE  or  RVMOEVT  is  “T” 

Range:  0-99 

SEEECTED 

MEASUREMENT 

NAME 

R-x\BME\SMN-n- 

m 

R/R  Ch  10  Status:  RO 

Specify  the  bus  measurement  name  to  be 
overwritten. 

Allowed  when:  RVBMEVN  >  0 

Required  when:  Allowed 

Einks  to:  B-xVMN-i-n-p 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 


Parameter 


Code  Name 


Usage  Attributes 


Definition 


Range:  32  characters 


MEASUREMENT 
OVERWRITE  TAG 


R-x\BME\MEOT- 

n-m 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\BME\N  >  0 


Indicate  if  the  bus  measurement  is  tagged  for 
overwriting. 


Range:  Enumeration 


Enumeration 


O 


N 


Description 


Overwrite 


No  overwriting 


Default:  N 


Analog  Data  Type  Attributes 


ANAEOG  DATA 
TYPE  EORMAT 


R-x\ATE-n 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\CDT  is  “ANAIN’ 


Required  when:  Allowed 


Range:  Enumeration 


Enumeration 


1 


Description 


Reserved 


Analog  data 


Analog  data  type  format.  Enumeration  equates 
to  format  number  in  Chapter  10. 


NUMBER  OE 

ANAEOG 

CHANNEES/PKT 


R-x\ACH\N-n 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\CDT  is  “ANAIN” 


Specify  the  number  of  analog  channels  per 
packet. 


Required  when:  Allowed 


Range:  Integer,  1-256 


DATA  PACKING 
OPTION 


R-x\ADP-n 


R/R  Ch  10  Status:  RO 


How  data  is  placed  in  the  packets. 


Allowed  when:  R\CDT  is  “ANAIN” 


Range:  Enumeration 


Enumeration 


YES 


NO 


Description 


Packed 


Unpacked 


Default:  YES 


SAMPEE  RATE 


R-x\ASR-n 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\CDT  is  “ANAIN” 


Sample  rate  of  the  fastest  channel(s)  in  samples 
per  second. 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 


Parameter 


Code  Name 


Usage  Attributes 


Definition 


Required  when:  Allowed 


Range:  positive  floating  point 


SUB  CHANNEL 
lABLED 


R-x\AMCE-n-m 


R/R  Ch  10  Status:  R 


Indieate  if  sub-ehannel  is  enabled. 


Allowed  when:  R\CDT  is  “ANAIN" 


Range:  Enumeration 


Enumeration 


Description 


True 


Ealse 


Default:  T 


SUB  CHANNEL 
NUMBER 


R-x\AMCN-n-m 


R/R  Ch  10  Status:  R 


Allowed  when:  R\CDT  is  “ANAIN’ 


Required  when:  Allowed 


Indicate  the  analog  sub  channel  number 
associated  with  the  -n-m  sub  channel.  Eirst 
subchannel  is  1 . 


Range:  1-256 


MEASUREMENT 

NAME 


R-x\AMN-n-m 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\CDT  is  “ANAIN” 


Required  when:  R-x\ACH\N  >  I 


Identify  the  measurement  name  consistent  with 
the  Data  Conversion  group  for  an  analog 
channel. 


Links  to:  C-d\DCN 


Range:  32  characters 


DATA  LENGTH 


R-x\ADL-n-m 


R/R  Ch  10  Status:  RO 


Number  of  bits  per  data  word. 


Allowed  when:  R\CDT  is  “ANAIN’ 


Required  when:  Allowed 


Range:  1-64 


BIT  MASK 


R-x\AMSK-n-m 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\CDT  is  “ANAIN’ 


Range:  Binary,  maximum  64  characters  or  “EW” 
Default:  EW 


Binary  string  of  Is  and  Os  to  identify  the  bits  in 
a  word  location  that  are  assigned  to  this 
measurement.  If  the  full  word  is  used  for  this 
measurement,  enter  “EW.”  Left-most  bit 
corresponds  to  the  msb. 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

MEASUREMENT 

R-x\AMTO-n-m 

R/R  Ch  10  Status:  RO 

Define  the  first  bit  transferred  in  normal  time 

TRANSEER 

Allowed  when:  R\CDT  is  “ANAIN” 

sequence. 

U^ER 

Range:  Enumeration 

CHAi 

VGF 

Enumeration 

Description 

M 

msb  first 

E 

Isb  first 

D 

msb  first 

Default:  M 

SAMPEE  EACTOR 

R-x\ASE-n-m 

R/R  Ch  10  Status:  RO 

1/(2")  times  the  fastest  sample  rate  (defined 

Allowed  when:  R\CDT  is  “ANAIN” 

above)  gives  the  sample  rate  for  this  channel. 

Required  when:  Allowed 

Specify  the  value  “n”  in  this  field. 

Range:  0-63 

SAMPEE  EIETER 

R-x\ASBW-n-m 

R/R  Ch  10  Status:  RO 

Sample  filter  in  units  of  Hz. 

3DB  BANDWIDTH 

Allowed  when:  R\CDT  is  “ANAIN” 

Required  when:  Allowed 

Range:  positive  floating  point 

AC/DC  COUPEING 

R-x\ACP-n-m 

R/R  Ch  10  Status:  RO 

Analog  signal  coupling. 

Allowed  when:  R\CDT  is  “ANAIN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

A 

AC  Coupled 

D 

DC  Coupled 

RECORDER 

R-x\AII-n-m 

R/R  Ch  10  Status: 

RO 

Analog  signal  input  impedance  to  the  recorder. 

INPUT 

Allowed  when:  R\CDT  is  “ANAIN” 

Units  of  ohms. 

IMPEDANCE 

Required  when:  Allowed 

Range:  positive  floating  point 

INPUT  CHANNEE 

R-x\AGTn-m 

R/R  Ch  10  Status:  RO 

Signal  gain  of  analog  signal.  Milli  units  (lOx  = 

GAIN 

Allowed  when:  R\CDT  is  “ANAIN” 

010000). 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 


Parameter 

Code  Name 

Usage  Attributes 

Definition 

Required  when:  Allowed 

Range:  positive  floating  point 

INPUT  FULL 

SCALE  RANGE 

R-x\AESI-n-m 

R/R  Ch  10  Status:  RO 

Eull-scale  range  of  input  signal.  Units  of 
millivolts  (20vpp  =  020000)  (vpp  =  2xvp). 

Allowed  when:  R\CDT  is  “ANAIN” 

Required  when:  Allowed 

Range:  positive  floating  point 

INPUT  OEESET 
VOETAGE 

R-x\AOVI-n-m 

R/R  Ch  10  Status:  RO 

Offset  voltage  of  input  signal.  Units  of 
millivolts  (10v=0 10000). 

Allowed  when:  R\CDT  is  “ANAIN” 

Required  when:  Allowed 

Range:  positive  floating  point 

RECORDED 

ANAEOG 

EORMAT 

R-x\AE-n-m 

R/R  Ch  10  Status:  RO 

Eormat  of  input  signal. 

Allowed  when:  R\CDT  is  “ANAIN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

1 

One’s  complement 

2 

Two’s  complement 

3 

(Sign  and  magnitude  binary 
[+=0]) 

4 

(Sign  and  magnitude  binary 
[+=1]) 

B 

Offset  binary 

U 

Unsigned  binary 

E 

(IEEE  754  single-precision 
[IEEE  32]  floating  point) 

INPUT  TYPE 

R-x\AIT-n-m 

R/R  Ch  10  Status: 

RO 

Type  of  input  signal. 

Allowed  when:  R\CDT  is  “ANAIN” 

Required  when:  Allowed 

Range:  Enumeration 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Enumeration 

Description 

S 

Single-ended 

D 

Differential 

AUDIO 

R-x\AV-n-m 

R/R  Ch  10  Status: 

RO 

Indicate  if  input  signal  is  audio. 

Allowed  when:  R\CDT  is  “ANAIN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

Y 

Audio  present 

N 

Audio  not  present 

AUDIO  FORMAT 

R-x\AVE-n-m 

R/R  Ch  10  Status: 

RO 

Eormat  of  audio  if  present. 

Allowed  when:  R\AV  is  “Y” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

RAW 

Raw,  headerless  PCM 

WAV 

Waveform  Audio 

EPCM 

Einear  PCM 

ACS 

Dolby  AC-3 

PRED 

“PRED”  format 

PSTD 

“PSTD”  format 

CVSD 

Continuously  Variable  Slope 
Delta  modulation 

0 

Other 

Discrete  Data  Type  Attributes 

DISCRETE  DATA 
TYPE  EORMAT 

R-x\DTE-n 

R/R  Ch  10  Status:  RO 

Discrete  data  type  format.  Enumeration 
equates  to  format  number  in  Chapter  10. 

Allowed  when:  R\CDT  is  “DISIN” 

Required  when:  Allowed 

Range:  Enumeration 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

Enumeration 

Description 

0 

Reserved 

I 

Discrete  data 

DISCRETE  MODE 

R-x\DMOD-n 

R/R  Ch  10  Status: 

RO 

Indicate  the  mode  whereby  discrete  events  are 

Allowed  when:  R\CDT  is  “DISIN” 

placed  in  the  packets. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

EV 

Event  mode 

SAMP 

Sample  mode 

SAMPLE  RATE 

R-x\DSR-n 

R/R  Ch  10  Status: 

RO 

Sample  rate  in  samples  per  second. 

Allowed  when:  R\CDT  is  “DISIN” 

Required  when:  Allowed 

Range:  positive  floating  point 

NUMBER  OE 

R-x\NDM\N-n 

R/R  Ch  10  Status:  RO 

Specify  the  number  of  discrete  measurements. 

DISCRETE 

Allowed  when:  R\CDT  is  “DISIN” 

MEASUREMENTS 

Required  when:  Allowed 

Range:  0-999 

MEASUREMENT 

R-x\DMN-n-m 

R/R  Ch  10  Status:  RO 

Identify  the  measurement  name  consistent  with 

NAME 

Allowed  when:  R\NDM\N  >  0 

the  data  conversion  group  for  one  or  more 

Required  when:  Allowed 

discrete  bits. 

Links  to:  C-d\DCN 

Range:  32  characters 

BIT  MASK 

R-x\DMSK-n-m 

R/R  Ch  10  Status:  RO 

Binary  string  of  Is  and  Os  to  identify  the  bits  in 

Allowed  when:  R\NDM\N  >  0 

a  word  location  that  are  assigned  to  this 

Required  when:  Allowed 

measurement.  If  the  full  word  is  used  for  this 

Range:  Binary,  max  16  characters  or  “EW 

measurement,  enter  “EW”.  Left-most  bit 
corresponds  to  the  msb. 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

MEASUREMENT 

R-x\DMTO-n-m 

R/R  Ch  10  Status:  RO 

Shows  msbs  and  least  significant  bits  (Isbs). 

TRANSEER 

Allowed  when:  R\NDM\N  >  0 

ORDER 

Range:  Enumeration 

Enumeration 

Description 

M 

msb  first 

E 

Isb  first 

D 

msb  first 

Default:  M 

ARINC  429  Bus  Data  Type  Attributes 

ARINC  429  BUS 

R-x\ABTE-n 

R/R  Ch  10  Status:  RO 

ARINC  429  bus  data  type  format.  Enumeration 

DATA  TYPE 

Allowed  when:  R\CDT  is  “429IN” 

equates  to  format  number  in  Chapter  10. 

EORMAT 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

ARINC  429  data 

1 

Reserved 

NUMBER  OE 

R-x\NAS\N-n 

R/R  Ch  10  Status: 

RO 

Number  of  ARINC  429  bus  sub-channels. 

ARINC  429  SUB- 

Allowed  when:  R\CDT  is  “429IN” 

CHANNEES 

Required  when:  Allowed 

Range:  1-256 

ARINC  429  SUB- 

R-x\ASN-n-m 

R/R  Ch  10  Status:  RO 

ARINC  429  bus  sub-channel  ID.  Eirst  sub- 

CHANNEE 

Allowed  when:  R\NAS\N  >  0 

channel  is  1 . 

NUMBER 

Required  when:  Allowed 

Range:  1-256. 

ARINC  429  SUB- 

R-x\ANM-n-m 

R/R  Ch  10  Status:  RO 

ARINC  429  bus  sub-channel  name. 

CHANNEE  NAME 

Allowed  when:  RVNASVN  >  0 

Required  when:  Allowed 

Range:  32  characters 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

Video  Data  Type  Attributes 

VIDEO  DATA 

R-xWTE-n 

R/R  Ch  10  Status:  RO 

Video  data  type  format.  Enumeration  equates 

TYPE  EORMAT 

Allowed  when:  R\CDT  is  “VIDIN” 

to  format  number  in  Chapter  10. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

MPEG-2/H.264 

1 

MPEG-2  ISO  13818 

2 

MPEG-4  ISO  14496 

MPEG-2 

R-xWXE-n 

R/R  Ch  10  Status: 

RO 

Type  of  video  carried  for  XON2  formats 

CHANNEE  XON2 

Allowed  when:  R\CDT  is  “VIDIN” 

(MPEG- 2  video  channels). 

EORMAT 

Required  when:  Allowed 

“0”  (20N2  [MPEG-2]).  “1”  (2640N2 

Range:  Enumeration 

[H.264]). 

Enumeration 

Description 

0 

20N2  (MPEG-2) 

1 

2640N2  (H.264) 

VIDEO  SIGNAE 

R-xWST-n 

R/R  Ch  10  Status: 

RO 

The  video  signal  input  type. 

TYPE 

Allowed  when:  R\CDT  is  “VIDIN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

Auto  detect 

1 

Composite 

2 

YUV 

3 

S-VIDEO 

4 

DVI 

5 

RGB 

6 

SDI 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

7 

VGA 

VIDEO  SIGNAL 

R-xWSF-n 

R/R  Ch  10  Status:  RO 

The  video  signal  input  type. 

FORMAT  TYPE 

Allowed  when:  R\CDT  is  “VIDIN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

Auto  detect 

1 

NTSC 

2 

PAL 

3 

ATSC 

4 

DVB 

5 

ISDB 

6 

SECAM 

VIDEO 

R-x\CBR-n 

R/R  Ch  10  Status: 

RO 

Contains  aggregate  stream  bit  rate  in  bits  per 

CONSTANT  BIT 

Allowed  when:  R\CDT  is  “VIDIN” 

second. 

RATE 

Required  when:  Allowed 

Range:  positive  floating  point 

VIDEO  VARIABLE 

R-xWBR-n 

R/R  Ch  10  Status:  RO 

Contains  peak  stream  bit  rate  in  bits  per  second. 

PEAK  BIT  RATE 

Allowed  when:  R\CDT  is  “VIDIN” 

Required  when:  Allowed 

Range:  positive  floating  point 

VIDEO 

R-xWED-n 

R/R  Ch  10  Status:  RO 

Delay  introduced  by  video  encoding  hardware 

ENCODING 

Allowed  when:  R\CDT  is  “VIDIN” 

in  milliseconds. 

DELAY 

Required  when:  Allowed 

Range:  positive  floating  point 

OVERLAY 

R-x\VCO\OE-n 

Allowed  when:  R\CDT  is  “VIDIN” 

Indicate  if  overlay  is  enabled. 

ENABLED 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

T 

True 

E 

Ealse 

OVERLAY  X 

R-x\VCO\X-n 

Allowed  when:  R\VCO\OE  is  “T” 

Specify  the  X  pixel  position  of  the  overlay  in 

POSITION 

Required  when:  Allowed 

the  video  channel.  Zero  indicates  the  leftmost 

Range:  0-99999 

position  of  the  video  image. 

OVERLAY  Y 

R-x\VCO\Y-n 

Allowed  when:  R\VCO\OE  is  “T” 

Specify  the  Y  line  position  of  the  overlay  in  the 

POSITION 

Required  when:  Allowed 

video  channel.  Zero  indicates  the  uppermost 

Range:  0-99999 

position  of  the  video  image. 

OVERLAY  EVENT 

R-x\VCO\OET-n 

Allowed  when:  R\VCO\OE  is  “T” 

Indicate  if  overlay  event  toggle  is  enabled. 

TOGGLE 

Required  when:  Allowed 

ENABLED 

Range:  Enumeration 

Enumeration 

Description 

T 

True 

E 

Ealse 

OVERLAY 

R-x\VCO\OLE-n 

Allowed  when:  R\VCO\OE  is  “T” 

Indicate  format  of  the  time  overlay. 

EORMAT 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

DT 

Day  and  time 
(DDD:HH:MM:SS) 

TO 

Time  only  (HH:MM:SS) 

TM 

Time  and  milliseconds 
(HH:MM:SS:SSS) 

DTM 

Day,  time,  and  milliseconds 
(DDD:HH:MM:SS:SSS) 

OVERLAY 

R-x\VCO\OBG-n 

Allowed  when:  R\VCO\OE  is  “T” 

Indicate  background  of  the  time  overlay. 

BACKGROUND 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 
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Parameter 


Code  Name 


Usage  Attributes 


Definition 


EOT 


WOT 


BOW 


WOE 


Black  on  transparent 


White  on  transparent 


Black  on  white 


White  on  black 


ANALOG  AUDIO 
CHANNEL  INPUT 
LEFT 


R-x\ASI\ASE-n 


Allowed  when:  R\CDT  is  “VIDIN” 


Range:  1-65536 


Indicate  the  analog  channel  source  of  the  left 
audio  channel  ID  for  the  video  channel. 


ANAEOG  AUDIO 
CHANNEL  INPUT 
RIGHT 


R-x\ASI\ASR-n 


Allowed  when:  R\CDT  is  “VIDIN” 


Range:  1-65536 


Indicate  the  analog  channel  source  of  the  right 
audio  channel  ID  for  the  video  channel. 


VIDEO  DATA 
ALIGNMENT 


R-xWDA-n 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\CDT  is  “VIDIN” 


Specify  the  data  alignment  of  the  video  data 
within  the  packet. 


Required  when:  Allowed 


Range:  Enumeration 


Enumeration 


E 


B 


Description 


Eittle  endian 


Big  endian 


Time  Data  Type  Attributes 


TIME  DATA  TYPE 
FORMAT 


R-x\TTF-n 


R/R  Ch  10  Status:  R 


Allowed  when:  R\CDT  is  “TIMEIN” 


Required  when:  Allowed 


Range:  Enumeration 


Enumeration 


Description 


Reserved 


Time  data 


Network  time 


Time  data  type  format.  Enumeration  equates  to 
format  number  in  Chapter  10. 


TIME  FORMAT 


R-x\TFMT-n 


R/R  Ch  10  Status:  R 


Allowed  when:  R\CDT  is  “TIMEIN” 


Range:  Enumeration 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

Enumeration 

Description 

Indicate  the  format  for  the  time.  Por  additional 

A 

IRIG-A  Ixy 

information,  see  RCC  200-04. '  y  is  an  optional 

B 

IRIG-B  Ixy 

last  digit. 

G 

IRIG-G  Ixy 

I 

Internal 

N 

Native  GPS  time 

U 

UTC  time  from  GPS 

X 

None 

0 

Network  Time  Protocol 

iAN<^  5^ 

Version  3  RPC- 1305 

I 

IEEE  Std  1588-2002 

2 

IEEE  Std  1588-2008 

Default:  A 

TIME  SOURCE 

R-x\TSRC-n 

R/R  Ch  10  Status:  R 

Indicate  the  time  source. 

Allowed  when:  R\CDT  is  “TIMEIN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

I 

Internal 

E 

External 

R 

Internal  from  RMM 

X 

None 

Image  Data  Type  Attributes 

IMAGE  DATA 

R-xMTE-n 

R/R  Ch  10  Status:  RO 

Image  data  type  format.  Enumeration  equates 

TYPE  EORMAT 

Allowed  when:  R\CDT  is  “IMGIN” 

to  format  number  in  Chapter  10. 

Required  when:  Allowed 

'  Range  Commanders  Council.  ‘TRIG  Serial  Time  Code  Formats.”  RCC  200-04.  May  be  superseded  by  update.  Retrieved  4  June  2015.  Available  at 
http://www.wsmr.armv.mil/RCCsite/Documents/200-04  lRlG%20Serial%20Time%20Code%20Formats/. 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

Range:  Enumeration 

Enumeration 

Description 

0 

Image 

1 

Still  imagery 

2 

Dynamic  imagery 

STILL  IMAGE 

R-x\SIT-n 

R/R  Ch  10  Status: 

RO 

Type  of  still  imagery  format. 

TYPE 

Allowed  when:  R\CDT  is  “IMGIN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

NITE 

1 

JPEG 

2 

JPEG2 

3 

PNG 

DYNAMIC  IMAGE 

R-x\DIE-n 

R/R  Ch  10  Status: 

RO 

Type  of  dynamic  imagery  format  lAW 

EORMAT 

Allowed  when:  R\CDT  is  “IMGIN” 

Genicam  standard  features  naming  convention 

Required  when:  Allowed 

vL5  or  later  and  GigE  Vision  v  1.2  or  later. 

Range:  Enumeration 

(Permitted  enumerated  values  are  per  standards 
referenced  in  the  Definition  column  or  the  word 
DEVICESPECIEIC  for  any  imagery  format  not 
referenced  by  those  standards.) 

IMAGE  TIME 

R-xMTSM-n 

R/R  Ch  10  Status:  RO 

Individual  image  time  stamp  mode. 

STAMP  MODE 

Allowed  when:  R\CDT  is  “IMGIN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

Image  capture  time 

1 

Image  packetization  time 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

DYNAMIC  IMAGE 

ACQUISITION 

MODE 

R-x\DIAM-n 

R/R  Ch  10  Status:  RO 

Dynamic  image  acquisition  mode.  “0”  (Single 
frame).  “1”  (Multi-frame).  “2”  (Continuous). 

Allowed  when:  R\CDT  is  “IMGIN” 

IMAGE  ERAME 
RATE 

R-xMER-n 

R/R  Ch  10  Status:  RO 

Erame  rate  in  frames  per  second  at  which  the 
frames  are  captured  or  streamed  in  continuous 
mode. 

Required  when:  Allowed 

Range:  positive  floating  point 

PRE-TRIGGER 

ERAMES 

R-x\PTG-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Number  of  frames  to  capture  before  acquisition 
trigger. 

Range:  positive  floating  point 

TOTAE  ERAMES 

R-x\TOTE-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Total  number  of  frames  to  be  captured 
including  pre-trigger  frames. 

Range:  positive  floating  point 

EXPOSURE  TIME 

R-x\EXP-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Image  exposure  time  in  microseconds  including 
fractional  seconds  if  desired. 

Range:  positive  floating  point 

SENSOR 

ROTATION 

R-x\ROT-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Sensor  rotation  0-359. 

Range:  0-359 

SENSOR  GAIN 
VAEUE 

R-x\SGV-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Sensor  gain  value  in  dB. 

Range:  floating  point 

SENSOR  AUTO 
GAIN 

R-x\SAG-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Sensor  auto  gain. 

Range:  Enumeration 

Enumeration 

Description 

0 

Off 

1 

On 

SENSOR  WIDTH 

R-xMSW-n 

R/R  Ch  10  Status: 

RO 

Effective  sensor  width  in  pixels  used  to  capture 
images. 

Allowed  when:  R\CDT  is  “IMGIN” 

Required  when:  Allowed 

Range:  1-9999999 

SENSOR  HEIGHT 

R-xMSH-n 

R/R  Ch  10  Status:  RO 

Effective  sensor  height  in  pixels  used  to  capture 
images. 

Allowed  when:  R\CDT  is  “IMGIN” 

Required  when:  Allowed 

Range:  1-9999999 

9-72 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  9,  July  2017 


Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

MAXIMUM 

IMAGE  WIDTH 

R-x\MIW-n 

R/R  Ch  10  Status:  RO 

Maximum  image  width  in  pixels. 

Allowed  when:  R\CDT  is  “IMGIN” 

Required  when:  Allowed 

Range:  1-9999999 

MAXIMUM 

IMAGE  HEIGHT 

R-x\MIH-n 

R/R  Ch  10  Status:  RO 

Maximum  image  height  in  pixels. 

Allowed  when:  R\CDT  is  “IMGIN” 

Required  when:  Allowed 

Range:  Integer,  1-9999999 

IMAGE  WIDTH 

R-xMW-n 

R/R  Ch  10  Status:  RO 

Image  width  in  pixels. 

Allowed  when:  R\CDT  is  “IMGIN” 

Required  when:  Allowed 

Range:  1-9999999 

IMAGE  HEIGHT 

R-xMH-n 

R/R  Ch  10  Status:  RO 

Image  height  in  pixels. 

Allowed  when:  R\CDT  is  “IMGIN” 

Required  when:  Allowed 

Range:  1-9999999 

IMAGE  OEESET  X 

R-xMOX-n 

R/R  Ch  10  Status:  RO 

Image  horizontal  offset  from  origin  to  area  of 
interest  in  pixels. 

Allowed  when:  R\CDT  is  “IMGIN” 

Required  when:  Allowed 

Range:  1-9999999 

IMAGE  OEESET  Y 

R-xMOY-n 

R/R  Ch  10  Status:  RO 

Image  vertical  offset  from  origin  to  area  of 
interest  in  pixels. 

Allowed  when:  R\CDT  is  “IMGIN” 

Required  when:  Allowed 

Range:  1-9999999 

EINE  PITCH 

R-xMEP-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Total  number  of  bytes  between  two  successive 
lines. 

Range:  1-999999999 

BINNING 

HORIZONTAE 

R-xMBH-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Number  of  horizontal  photo-sensitive  cells  to 
combine  together.  A  value  of  1  indicates  no 
horizontal  binning. 

Range:  1-9999999 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

BINNING 

VERTICAL 

R-xMBV-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Number  of  vertical  photo-sensitive  cells  to 
combine  together.  A  value  of  1  indicates  no 
vertical  binning. 

Range:  1-9999999 

DECIMATION 

HORIZONTAL 

R-xMDH-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Horizontal  sub-sampling  of  the  image.  A  value 
of  1  indicates  no  horizontal  decimation. 

Range:  1-9999999 

DECIMATION 

VERTICAL 

R-xMDV-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Vertical  sub-sampling  of  the  image.  A  value  of 

1  indicates  no  vertical  decimation. 

Range:  1-9999999 

REVERSE  X 

R-xMRX-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Elip  horizontally  the  image  sent  by  the  device. 
“T”  (True).  “E”  (Ealse). 

Range:  Enumeration 

REVERSE  Y 

R-xMRY-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Elip  vertically  the  image  sent  by  the  device. 

Range:  Enumeration 

Enumeration 

Description 

T 

True 

E 

Ealse 

PIXEL  DYNAMIC 
RANGE 

MINIMUM 

R-xMPMN-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Minimum  value  that  can  be  returned  during  the 
digitization  process. 

Range:  1-9999999 

PIXEL  DYNAMIC 
RANGE 

MAXIMUM 

R-xMPMX-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Maximum  value  that  can  be  returned  during  the 
digitization  process. 

Range:  1-9999999 

TEST  IMAGE 

TYPE 

R-x\TIT-n 

Allowed  when:  R\CDT  is  “IMGIN” 

Type  of  test  image  sent  by  the  camera. 

Range:  Enumeration 

Enumeration 

OLE 

BLACK 

WHITE 

GREYHORIZONTALRAMP 

GREYVERTICALRAMP 

GREYHORIZONTALRAMPMOVING 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

GREYVERTICAERAMPMOVING 

HORIZONTAEEINEMOVING 

VERTICAEEINEMOVING 

COEORBAR 

FRAMECOUNTER 

DEVICESPECIFIC 

UART  Data  Type  Attributes 

UART  DATA 

TYPE  FORMAT 

R-x\UTF-n 

R/R  Ch  10  Status:  RO 

UART  data  type  format. 

Allowed  when:  R\CDT  is  “UARTIN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

Format  0 

1 

Format  1 

NUMBER  OF 

UART  SUB- 
CHANNEES 

R-x\NUS\N-n 

R/R  Ch  10  Status: 

RO 

Specify  the  number  of  UART  sub-channels 
included  within  this  channel. 

Allowed  when:  R\CDT  is  “UARTIN” 

Required  when:  Allowed 

Range:  1-256 

UART  SUB- 

CHANNEE 

NUMBER 

R-x\USCN-n-m 

R/R  Ch  10  Status:  RO 

Specify  the  UART  sub-channel  number.  First 
sub-channel  is  1 . 

Allowed  when:  R\NUS\N  >  0 

Required  when:  Allowed 

Range:  1-256 

UART  SUB- 
CHANNEE  NAME 

R-x\UCNM-n-m 

R/R  Ch  10  Status:  RO 

Specify  the  UART  sub-channel  name. 

Allowed  when:  R\NUS\N  >  0 

Required  when:  Allowed 

Range:  32  characters 

UART  SUB- 
CHANNEE  BAUD 
RATE 

R-x\UCR-n-m 

R/R  Ch  10  Status:  RO 

Baud  rate  in  bits  per  second. 

Allowed  when:  R\NUS\N  >  0 

Required  when:  Allowed 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

Range:  positive  floating  point 

UART  SUB¬ 
CHANNEL  BITS 
PER  WORD 

R-x\UCB-n-m 

R/R  Ch  10  Status:  RO 

Bits  per  word  (7,  8,  or  9). 

Allowed  when:  R\NUS\N  >  0 

Required  when:  Allowed 

Range:  7,  8,  or  9 

UART  SUB¬ 
CHANNEL 

PARITY 

R-x\UCP-n-m 

R/R  Ch  10  Status:  RO 

Allowed  when:  R\NUS\N  >  0 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

Odd 

E 

Even 

N 

None 

UART  SUB¬ 
CHANNEL  STOP 
BIT 

R-x\UCS-n-m 

R/R  Ch  10  Status: 

RO 

Stop  bit  size. 

Allowed  when:  R\NUS\N  >  0 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

1.0 

1 

1.5 

2 

2.0 

UART  SUB¬ 
CHANNEL 
INTERLACE 

R-x\UCIN-n-m 

Allowed  when:  R\NUS\N  >  0 

UART  interface. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

Other 

1 

RS-232 

2 

RS-422 

3 

RS-485 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 


Parameter 


Code  Name 


Usage  Attributes 


Definition 


TTL 


UART  SUB¬ 
CHANNEL  BLOCK 
SIZE 


R-x\UCBS-n-m 


Allowed  when:  R\NUS\N  >  0 


Block  (frame)  size  in  words. 


Required  when:  Allowed 


Range:  Integer,  0-999999 


UART  SUB- 
ANNEL  SYNC 
WORD  LENGTH 


R-x\UCSL-n-m 


Allowed  when:  R\UCBS  >  1 


Sync  word  length  in  words. 


Required  when:  Allowed 


Range:  0-9 


UART  SUB- 

ANNEL  BLOCK 
SYNC  VALUE 


R-x\UCSV-n-m 


Allowed  when:  R\UCBS  >  1 


Required  when:  Allowed 


Block  sync  word  value  in  binary.  Specify  all 
bits. 


Range:  Binary,  81  binary  digits 


UART  SUB¬ 
CHANNEL  BLOCK 
RATE 


R-x\UCBR-n-m 


Allowed  when:  R\NUS\N  >  0 


Block  rate  in  Hz 


Range:  positive  floating  point 


Message  Data  Type  Attributes 


MESSAGE  DATA 
TYPE  EORMAT 


R-x\MTE-n 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\CDT  is  “MSGIN" 


Required  when:  Allowed 


Range:  Enumeration 


Enumeration 


0 


Description 


message  data 


Message  data  type  format.  Enumeration 
equates  to  format  number  in  Chapter  10. 


NUMBER  OE 
MESSAGE  SUB¬ 
CHANNELS 


R-x\NMS\N-n 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\CDT  is  “MSGIN" 


Specify  the  number  of  message  sub-channels 
included  within  this  channel. 


Required  when:  Allowed 


Range:  1-256 


MESSAGE  SUB¬ 
CHANNEL 
NUMBER 


R-x\MSCN-n-m 


R/R  Ch  10  Status:  RO 


Allowed  when:  RVNMSVN  >  0 


Specify  the  message  sub-channel  number.  The 
first  sub-channel  is  1 . 


Required  when:  Allowed 


Range:  Integer,  1-256 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

MESSAGE  SUB¬ 
CHANNEL  NAME 

R-x\MCNM-n-m 

R/R  Ch  10  Status:  RO 

Specify  the  message  sub-channel  name. 

Allowed  when:  R\NMS\N  >  0 

Required  when:  Allowed 

Range:  32  characters 

IEEE- 1394  Data  Type  Attributes 

IEEE- 1394  DATA 
TYPE  EORMAT 

R-xMETE-n 

R/R  Ch  10  Status:  RO 

IEEE- 1394  data  type  format.  Enumeration 
equates  to  format  number  in  Chapter  10. 

Allowed  when:  R\CDT  is  ‘T394IN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

IEEE- 1394  TRANS 

1 

IEEE- 1394  PHY 

Paral 

el  Data  Type  Attributes 

PARALLEL  DATA 
TYPE  EORMAT 

R-x\PLTE-n 

R/R  Ch  10  Status:  RO 

Parallel  data  type  format.  Enumeration  equates 
to  format  number  in  Chapter  10. 

Allowed  when:  R\CDT  is  “PARIN’’ 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

Parallel 

Ethernet  Data  Type  Attributes 

ETHERNET  DATA 
TYPE  EORMAT 

R-x\ENTE-n 

R/R  Ch  10  Status:  RO 

Ethernet  data  type  format.  Enumeration 
equates  to  format  number  in  Chapter  10. 

Allowed  when:  R\CDT  is  “ETHIN” 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

Ethernet  data 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

NUMBER  OF 

ETHERNET 

NETWORKS 

R-x\NNET\N-n 

R/R  Ch  10  Status:  RO 

Specify  the  number  of  Ethernet  networks 
included  within  this  channel. 

Allowed  when:  R\CDT  is  “ETHIN” 

Required  when:  Allowed 

Range:  1-256 

ETHERNET 

NETWORK 

NUMBER 

R-x\ENBR-n-m 

R/R  Ch  10  Status:  RO 

Specify  the  Ethernet  network  number.  The  first 
network  number  is  1 . 

Allowed  when:  R\NNET\N  >  0 

Required  when:  Allowed 

Range:  Integer,  1-256 

ETHERNET 
NETWORK  NAME 

R-x\ENAM-n-m 

R/R  Ch  10  Status:  RO 

Specify  the  Ethernet  network  name. 

Allowed  when:  R\NNET\N  >  0 

Required  when:  Allowed 

Range:  32  characters 

Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 


TSPI/CTS  Data  Type  Attributes 


TSPECTS  DATA 

R-x\TDTF-n 

R/R  Ch  10  Status:  RO 

TSPECTS  data  type  format.  Enumeration 

TYPE  FORMAT 

Allowed  when:  R\CDT  is  “TSPIN” 

equates  to  format  number  in  Chapter  10. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

0 

NMEA-RTCM 

1 

EAG  ACMI 

2 

ACTTS 

CAN  Bus  Data  Type  Attributes 


CAN  BUS  DATA 
TYPE  FORMAT 


R-x\CBTF-n 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\CDT  is  “CANIN’ 


Required  when:  Allowed 


Range:  Enumeration 


Enumeration 


Description 


CAN  bus 


CAN  bus  data  type  format.  Enumeration 
equates  to  format  number  in  Chapter  10. 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

NUMBER  OE  CAN 
BUS  SUB¬ 
CHANNELS 

R-x\NCB\N-n 

R/R  Ch  10  Status:  RO 

Specify  the  number  of  CAN  bus  sub-channels 
in  the  packet. 

Allowed  when:  R\CDT  is  “CANIN” 

Required  when:  Allowed 

Range:  1-256 

CAN  BUS  SUB¬ 
CHANNEL 
NUMBER 

R-x\CBN-n-m 

R/R  Ch  10  Status:  RO 

Specify  the  CAN  bus  sub-channel  ID.  Eirst 
sub-channel  is  1 . 

Allowed  when:  RVNCBVN  >  0 

Required  when:  Allowed 

Range:  1-256 

CAN  BUS  SUB¬ 
CHANNEL  NAME 

R-x\CBM-n-m 

R/R  Ch  10  Status:  RO 

Specify  the  CAN  bus  sub-channel  name. 

Allowed  when:  R\NCB\N  >  0 

Required  when:  Allowed 

Range:  32  characters 

CAN  BUS  BIT 

RATE 

R-x\CBBS-n-m 

R/R  Ch  10  Status:  RO 

Specify  the  bit  rate  of  the  CAN  bus  sub-channel 
in  bits  per  second. 

Allowed  when:  R\NCB\N  >  0 

Required  when:  Allowed 

Range:  1-256 

Fibre  Channel  Data  Type  Attributes 

FIBRE  CHANNEL 
DATA  TYPE 
EORMAT 


R-x\ECTE-n 


R/R  Ch  10  Status:  RO 


Allowed  when:  R\CDT  is  “EBCHIN” 


Required  when:  Allowed 


Range:  Enumeration 


Enumeration 


1 


Description 


EC-PH 


EC-ES 


Eibre  Channel  data  type  format 


EIBRE  CHANNEL 
SPEED 


R-x\ECSP-n 


*  R/R  Ch  10  Status:  RO 


Allowed  when:  R\CDT  is  “EBCHIN” 


Eibre  Channel  speed  (bit  rate)  for  the  port  for 
frame  capture. 


Required  when:  Allowed 


Range:  Enumeration 


Enumeration 


Description 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

0 

IGEC  (1.0625  gigabits  per 
second  [Gbps]) 

1 

2GEC  (2.125  Gbps) 

2 

4GEC  (4.25  Gbps) 

3 

8GEC  (8.5  Gbps) 

4 

lOGEC  (10.52  Gbps) 

5 

16GEC  (14.025  Gbps) 

6 

32GEC  (28.05  Gbps) 

Telemetry  Output 

OUTPUT  STREAM 
NAME 

R-x\OSNM-n 

Allowed  when:  R\CDT  is  “TMOUT” 

Specify  the  recorder-reproducer  channel  group 
stream  name  to  be  included  in  the  telemetry 
output. 

Required  when:  Allowed 

Einks  to:  R-x\CGNM-n 

Range:  32  characters 

STREAM  ID 

R-x\SID-n 

Allowed  when:  R\CDT  is  “TMOUT” 

Specify  the  stream  ID  for  the  minor  frame 
header  unprotected  part 

Range:  0-15 

Default:  0 

CONEIGURATION 
HASH  RATE 

R-x\HRATE-n 

Allowed  when:  R\CDT  is  “TMOUT” 

Specify  the  rate  of  the  Chapter  10  configuration 
packet  hash  code  insertion  into  the  telemetry 
output  in  seconds.  Value  0  allows  sending  once 
after  changes.  Use  character  “N”  for  disable. 

Range:  0-60,  N 

Default:  “N’,  disabled 

CONEIGURATION 
PACKET  RATE 

R-x\CRATE-n 

Allowed  when:  R\CDT  is  “TMOUT” 

Specify  the  rate  of  the  Chapter  10  configuration 
packet  insertion  into  the  telemetry  output  in 
seconds.  Value  0  allows  sending  once  after 
changes.  Use  character  “N”  for  disable. 

Range:  0-60,  N 

Default:  “N’,  disabled 

Reference  Track 

NUMBER  OE 
REEERENCE 
TRACKS 

R-x\RT\N 

Allowed  when:  R\NCB\N  >  0 

Specify  the  number  of  reference  tracks. 

Range:  1-9 

TRACK  NUMBER 

R-x\RTl-n 

Allowed  when:  R\RT\N  >  0 

State  the  track  location  of  the  reference  signal. 
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Table  9-4.  Recorder-Reproducer  Attributes  Group  (R) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Required  when:  Allowed 

Range:  1-99 

REFERENCE 

FREQUENCY 

R-x\RT2-n 

Allowed  when:  R\RT\N  >  0 

Frequency  of  reference  signal,  in  kHz. 

Required  when:  Allowed 

Range:  6  characters 

NOTE:  There  will  be  one  tape/storage  source  attributes  group  for  each  tape  or  storage  source. 

Comments 

COMMENTS 

R-x\COM 

R/R  Ch  10  Status:  RO 

Provide  the  additional  information  requested  or 
any  other  information  desired. 

Allowed  when:  R\ID  is  specified 

Range:  3200  characters 
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9.5.5  Multiplex/Modulation  (Mux/Mod)  Attributes  (M) 

The  composite  baseband  waveform  is  received  from  the  receiver  or  tape  reproducer 
electronics  and  is  passed  to  the  demultiplexer/demodulator  for  further  processing.  Figure  9-5 
summarizes  the  information  that  is  required  to  continue  processing  the  data.  The  composite 
baseband  waveform  may  consist  of  any  number  of  signals  that  are  modulated  directly  onto  the 
RF  carrier,  including  a  baseband  data  signal  and  one  or  more  subcarriers. 


The  baseband  data  signal  may  be  PCM  or  analog  data.  The  PCM  data  streams  must  be 
defined  in  terms  of  a  data  link  name.  This  data  link  name  is  unique  for  each  system  that  contains 
different  data,  has  a  different  format,  or  has  a  different  data  rate.  The  analog  measurand  is 
typically  converted  into  engineering  units  appropriate  for  the  measurand.  The  measurement 
name  provides  the  connection  to  the  Data  Conversion  Attributes  group  (C). 


Subcarriers,  both  standard  and  nonstandard,  may  be  part  of  the  baseband  composite 
waveform.  These,  in  turn,  may  be  modulated  with  PCM  or  analog  data.  As  with  the  baseband 
data  signal,  these  data  channels  must  be  defined.  Table  9-5  specifies  the  required  information  for 
the  data  signal  attributes. 


Figure  9-5.  Multiplex/Modulation  Attributes  Group  (M) 


DATA  SOURCE  ID  -  9-85 


9-85 


9-85 


9-86 


9-87 


9-87 


9-88 


*  Composite  Signal  Structure 


SIGNAL  STRUCTURE  TYPE 


MODUEATION  SENSE 


COMPOSITE  EPE  BANDWIDTH 


^Baseband  Signal 


BASEBAND  SIGNAE  TYPE 


*Low  Pass  Filter 


BANDWIDTH 


TYPE 


^Baseband  Data  Link  Type 


*PCM 


OR 


DATA  LINK  NAME 


^Analog 


MEASUREMENT  NAME 


*  Subcarriers 


NUMBER  OE  SUBCARRIERS 


*IRIG  Subcarriers 


NUMBER  OE  SCOs 


SCO  NUMBER 


SCO  #n  DATA  TYPE 


MODULATION  SENSE 


*Low  Pass  Filter 


BANDWIDTH 


TYPE 


*Data  Link  Type 


*PCM 


Code  Name 

(M-x\ID) 

(M-x\BBI) 

(M-x\BB2) 

(M-x\BB3) 

(M-x\BSGI) 

(M-x\BSEI) 

(M-x\BSE2) 


(M-x\BB\DLN) 

(M-x\BB\MN) 

(M-x\SCO\N) 

(M-x\SEN) 

(M-x\SH-n) 

(M-x\SI2-n) 

(M-x\SI3-n) 

(M-x\SIEI-n) 

(M-x\SIE2-n) 
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1  DATA  EINK  NAME 

(M-x\SEDEN-n) 

OR 

*Analog 

1  MEASUREMENT  NAME 

(M-x\SEMN-n) 

9-88 

OTHER 

(M-x\SO) 

REFERENCE  CHANNEE 

(M-x\RC) 

9-89 

*  Comments 

COMMENTS 

(M-x\COM) 

*Heading  Only  -  No  Data  Entry 
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Table  9-5.  Multiplex/Modulation  Group  (M) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

DATA  SOURCE 

ID 

M-xMD 

Allowed  when:  defining  multiplexed  data 

Data  source  identification. 

Required  when:  Allowed 

Links  from:  G\DSTn,  T-x\ID 

Range:  32  characters 

Composite  Signal  Structure 

SIGNAL 

STRUCTURE 

TYPE 

M-x\BBI 

Allowed  when:  M\ID  is  specified 

Specify  the  composite  baseband  signal  structure. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

PCM 

ANALOG 

SCO’s 

OTHER 

ANA/SCO 

Hybrid 

PCM/SCO 

Hybrid 

MODULATION 

SENSE 

M-x\BB2 

Allowed  when:  M\ID  is  specified 

Specify  the  modulation  sense:  “POS”  -  indicates  that  an 
increasing  voltage  results  in  an  increase  in  frequency. 

“NEG”  -  indicates  that  a  decreasing  voltage  results  in  an 
increase  in  frequency. 

Range:  Enumeration 

Enumeration 

Description 

POS 

NEG 

COMPOSITE  LPE 
BANDWIDTH 

M-x\BB3 

Allowed  when:  M\ID  is  specified 

Give  the  low  pass  bandwidth  of  the  composite  waveform 
(3  dB  cutoff  frequency),  in  kHz. 

Range:  6  characters 

Baseband  Signal 

BASEBAND 
SIGNAL  TYPE 

M-x\BSGI 

Allowed  when:  M\BB1  is  not  “SCO's”  or 
“OTHER' 

Type  of  baseband  data. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

PCM 
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Table  9-5.  Multiplex/Modulation  Group  (M) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

ANA 

Analog 

OTH 

Other 

NON 

None 

Low-Pass  Filter 

BANDWIDTH 

M-x\BSEI 

Allowed  when:  defining  multiplexed  data 

Specify  low  pass  filter  bandwidth  (3  dB  cutoff  frequency), 
in  kHz. 

Range:  6  characters 

TYPE 

M-x\BSE2 

Allowed  when:  defining  multiplexed  data 

Specify  the  filter  type. 

Range:  Enumeration 

Enumeration 

Description 

CA 

Constant  amplitude 

CD 

Constant  delay 

OT 

Other,  define  in  the 
comments 

I 

baseband  Data  Link  Type 

PCM 

DATA  LINK 
NAME 

M- 

x\BB\DLN 

Allowed  when:  M\BB1  is  not  “SCO's'  or 
“OTHER”  and  M\BSG1  is  “PCM” 

Specify  the  data  link  name  for  PCM  data  format. 

Required  When:  Allowed 

Links  to:  P-d\DLN 

Range:  32  characters 

Analog 

MEASUREMENT 

NAME 

M-x\BB\MN 

Allowed  when:  M\BB1  is  not  “SCO's”  or 
“OTHER”  and  M\BSG1  is  “ANA” 

Give  the  measurand  name. 

Required  When:  Allowed 

Links  to:  C-d\DCN 

Range:  32  characters 
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Table  9-5.  Multiplex/Modulation  Group  (M) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Subcarriers 

NUMBER  OF 
SUBCARRIERS 

M-x\SCO\N 

Allowed  when:  M\BB1  not  “PCM”  or 
“ANAEOG” 

Specify  the  number  of  subcarriers  on  this  data  link. 

Required  when:  Allowed 

Range:  2  characters 

IRIG  Subcarriers 

NUMBER  OF 

SCOS 

M-x\SI\N 

Allowed  when:  M\BB1  is  “SCO's”  or 
“ANA/SCO”  or  “PCM/SCO” 

Specify  the  number  of  IRIG  subcarriers. 

Required  when:  Allowed 

Range:  2  characters 

SCO  NUMBER 

M-x\SII-n 

Allowed  when:  M\SEN  >  0 

Give  the  IRIG  channel  number  for  the  subcarrier. 

Required  when:  Allowed 

Range:  5  characters 

SCO  #N  DATA 
TYPE 

M-x\SI2-n 

Allowed  when:  M\SEN  >  0 

Specify  the  type  of  data  on  the  subcarrier. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

PCM 

ANA 

Analog 

OTH 

Other 

MODUEATION 

SENSE 

M-x\SI3-n 

Allowed  when:  M\SEN  >  0 

Specify  the  modulation  sense:  “POS”  -  indicates  that  an 
increasing  voltage  results  in  an  increase  in  frequency. 

“NEG”  -  indicates  that  a  decreasing  voltage  results  in  an 
increase  in  frequency. 

Range:  Enumeration 

Enumeration 

Description 

POS 

NEC 

Low-Pass  Filter 

BANDWIDTH 

M-x\SIFI-n 

Allowed  when:  M\ID  is  specified 

Specify  the  low  pass  filter  cutoff  frequency  (3  dB),  in  kHz. 

Range:  6  characters 

TYPE 

M-x\SIF2-n 

Allowed  when:  M\ID  is  specified 

Specify  the  filter  type. 
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Table  9-5.  Multiplex/Modulation  Group  (M) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Range:  Enumeration 

Enumeration 

Description 

CA 

Constant  amplitude 

CD 

Constant  delay 

OT 

Other,  define  in  the 
comments 

Data  Link  Type 

PCM 

DATA  LINK 
NAME 

M- 

x\SEDEN-n 

Allowed  when:  M\BB1  is  not  “PCM”  or 
“ANAEOG”  and  M\SI2  is  “PCM” 

Specify  the  data  link  name  for  PCM  data  formats. 

Required  when:  Allowed 

Einks  to:  P-d\DEN 

Range:  32  eharaeters 

Analog 

MEASUREMENT 

NAME 

M-x\SI\MN- 

n 

Allowed  when:  M\BB1  is  not  “PCM”  or 
“ANAEOG”  and  M\SI2  is  “ANA” 

Give  the  measurand  name. 

Required  when:  Allowed 

Einks  to:  C-d\DCN 

Range:  32  eharaeters 

NOTE:  Repeat  the  above  for  eaeh  I 

?.IG  subearrier  on  this  earner. 

OTHER 

M-x\SO 

Allowed  when:  M\ID  is  specified 

Are  there  nonstandard  subcarriers?  Define  in  the 

comments. 

Range:  Enumeration 

Enumeration 

Description 

Y 

Yes 

N 

No 

Default:  N 

REEERENCE 

CHANNEE 

M-x\RC 

Allowed  when:  M\ID  is  specified 

Erequency  of  reference  channel  in  kHz,  if  applicable. 

Range:  6  characters 
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Table  9-5.  Multiplex/Modulation  Group  (M) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Comments 

COMMENTS 

M-x\COM 

Allowed  when:  M\ID  is  specified 

Provide  the  additional  information  requested  or  any  other 
information  desired. 

Range:  3200  characters 
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9.5.6  Digital  Data  Attributes  (P,  D,  B,  S) 

The  digital  data  attributes  are  separated  into  four  groups  eontaining  PCM-related  attribute 
information.  The  PCM  Format  Attributes  group  (P)  is  deseribed  in  item  a  below.  The  PCM 
Measurement  Description  Attributes,  contained  in  (D),  are  described  in  item  b.  Item  c  depicts 
the  MIL-STD-1553  or  ARINC  429  Bus  Data  Attributes  (B).  Item  d  describes  the  Message  Data 
Attributes  (S). 

a.  PCM  Format  Attributes  (P).  The  PCM  Format  Attributes  group  contains  the  information 
required  to  decommutate  the  PCM  data  stream.  Operations  of  both  Class  I  and  Class  II 
are  included.  Limited  information  is  incorporated  for  class  II  operations.  Figure  9-6 
presents  the  flow  and  summary  of  the  information  required.  In  general,  only  standard 
methods  of  synchronization  have  been  included  except  for  cases  where  considerable 
application  is  already  in  place.  Inclusion  should  not  be  taken  to  mean  that  the 
nonstandard  approaches  are  better  or  desired.  Table  9-6  contains  the  PCM  Format 
Attributes.  The  group  defines  and  specifies  the  frame  format  and  the  information 
necessary  to  set  up  the  PCM  decommutation.  Refer  to  Chapter  4  for  the  definition  of 
terms  (such  as  major  and  minor  frames  and  subframes)  and  word  numbering  conventions. 


Figure  9-6. 
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LENGTH 


PATTERN 


*  Synchronization  Criteria 
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SYNC  PATTERN  CRITERIA 
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SYNC  PATTERN  CRITERIA 

EIEE  BITS 
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MASK 

(P-d\EEI2) 

9-104 

^Measurement  List  Change 

NUMBER  OE  MEASUREMENT  EISTS 

(P-d\MEC\N) 

EEI  PATTERN 

(P-d\MECl-n) 
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(P-d\MEC2-n) 
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OR 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 


Parameter 


Code  Name 


Usage  Attributes 


Definition 


DATA  LINK 
NAME 


P-d\DLN 


R/R  Ch  10  Status:  RO 


Allowed  when:  defining  PCM  data 


Identify  the  data  link  name  consistent  with  the 
mux/mod  group. 


Required  when:  Allowed 


Links  from:  M-x\BB\DLN,  M-x\SI\DLN-n, 
R-x\CDLN,  P-d\AEF\DLN-n,  P-d\FSC2-n, 
P-d\ADM\DMN-n,  R-x\EV\DLN-n 


Links  to:  D-x\DLN,  B-d\DLN 


Range:  32  characters 


Input  Data 


PCM  CODE 

P-d\DI 

R/R  Ch  10  Status:  RO 

Define  the  data  format  code. 

Allowed  when:  P-d\DLN  is  specified 

A  randomized  PCM  stream  can  be  specified  as: 

Range:  Enumeration 

“P-d\Dl=NRZ-L”  and  “P-d\D7=Y”;  or 

Enumeration 

Description 

“P-d\Dl=RNRZ-L”  and  “P-d\D7”  is  ignored. 

NRZ-L 

Non-retum-to-zero-level 

NRZ-M 

Non-retum-to-zero-mark 

NRZ-S 

Non-retum-to-zero-space 

RNRZ-L 

Randomized,  non-retum- 
to-zero-level 

BIO-M 

Bi-phase-mark 

BIO-L 

Bi-phase-level 

BIO-S 

Bi-phase-space 

OTHER 

Other  encoding,  define  in 

comments 

Default:  NRZ-L 

BIT  RATE 

P-d\D2 

R/R  Ch  10  Status:  RO 

Data  rate  in  bits  per  second. 

Allowed  when:  P-d\DLN  is  specified 

Required  when:  Allowed 

Range:  positive  floating  point 

ENCRYPTED 

P-d\D3 

Allowed  when:  P-d\DLN  is  specified 

If  the  data  is  encrypted,  provide  details  in  comments. 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Range:  Enumeration 

Enumeration 

Description 

E 

Data  is  encrypted 

U 

Data  is  unencrypted 

Default:  U 

POLARITY 

P-d\D4 

R/R  Ch  10  Status:  RO 

Data  polarity. 

Allowed  when:  P-d\DEN  is  specified 

Range:  Enumeration 

Enumeration 

Description 

N 

Normal 

I 

Inverted 

Default:  N 

AUTO-POLARITY 

CORRECTION 

P-d\D5 

Allowed  when:  P-d\DEN  is  specified 

Is  automatic  polarity  correction  to  be  used? 

Range:  Enumeration 

Enumeration 

Description 

Y 

Yes 

N 

No 

Default:  N 

DATA 

DIRECTION 

P-d\D6 

Allowed  when:  P-d\DEN  is  specified 

Time  sequence  of  data. 

Range:  Enumeration 

Enumeration 

Description 

N 

Normal 

R 

Reversed 

Default:  N 

DATA 

RANDOMIZED 

P-d\D7 

R/R  Ch  10  Status:  RO 

Randomization  algorithm  is  specified  in 
“RANDOMIZER  EENGTH”  (P-d\D8). 

Allowed  when:  P-d\DEN  is  specified 

Range:  Enumeration 

Enumeration 

Description 

Y 

Yes 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

N 

No 

Default:  N 

RANDOMIZER 

LENGTH 

P-d\D8 

R/R  Ch  10  Status:  RO 

Specify  the  randomizer  length. 

Allowed  when:  P-d\D7  =  Y 

Range:  Enumeration 

Enumeration 

Description 

STD 

15  bits,  per  Annex  A. 2 

OTH 

Other,  define  in  comments 

N/A 

Not  applicable 

Default:  STD 

Format 

TYPE  EORMAT 

P-d\TP 

R/R  Ch  10  Status:  RO 

Type  of  PCM  format. 

Allowed  when:  P-d\DLN  is  specified 

Range:  Enumeration 

Enumeration 

Description 

ONE 

Class  I 

TWO 

Class  II 

BUS 

1553  bus 

1553 

1553  bus 

ALTD 

Alternate  tag  and  data 

OTHR 

Other,  define  in  comments 

Default:  ONE 

COMMON  WORD 
LENGTH 

P-d\Pl 

R/R  Ch  10  Status:  RO-PAK 

Number  of  bits  in  common  word  length. 

Allowed  when:  P-d\DLN  is  specified 

Required  when:  Allowed  and  defining 

CHIO  non-throughput  mode 

Range:  4-64 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

WORD 

P-d\E2 

R/R  Ch  10  Status:  RO-PAK 

Define  the  default  for  the  first  bit  transferred  in  normal 

TRANSFER 

Allowed  when:  P-d\DEN  is  specified 

time  sequence. 

ORDER 

Required  when:  Allowed  and  defining 

CHIO  non-throughput  mode 

Range:  Enumeration 

Enumeration 

Description 

M 

msb 

E 

Isb 

Default:  M 

PARITY 

P-d\E3 

R/R  Ch  10  Status:  RO-PAK 

Normal  word  parity. 

Allowed  when:  P-d\DEN  is  specified 

Required  when:  Allowed  and  defining 

CHIO  non-throughput  mode 

Range:  Enumeration 

Enumeration 

Description 

EV 

Even 

OD 

Odd 

NO 

None 

Default  NO 

PARITY 

P-d\E4 

Allowed  when:  P-d\E3  is  not  NO 

Parity  bit  location. 

TRANSEER 

Required  when:  Allowed 

ORDER 

Range:  Enumeration 

Enumeration 

Description 

E 

Eeads  word 

T 

Trails  word 

CRC 

P-d\CRC 

Allowed  when:  ] 

^-d\DEN  is  specified 

Specify  what  type  of  cyclic  redundancy  code  is  to  be 

Range:  Enumeration 

used. 

Enumeration 

Description 

A 

CRC-16-ANSI 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

C 

CRC-16-CCITT 

E 

CRC-32-ANSI 

N 

None 

Default:  N 

CRC  CHECK 

P-d\CRCCB 

Allowed  when: 

When  P-d\CRC  is  not  N 

The  starting  bit  number  in  the  minor  frame  where  the 

WORD  STARTING 

Required  when:  Allowed 

CRC  check  word  begins.  The  CRC  check  word  must 

BIT 

Range:  1  to  the  value  of  P-d\ME2 

occupy  contiguous  bits  of  the  minor  frame  even  if  the 
check  word  crosses  word  boundaries.  The  check  word 
shall  always  be  inserted  msb  first. 

CRC  DATA 

P-d\CRCDB 

Allowed  when: 

When  P-d\CRC  is  not  N 

The  starting  bit  number  in  the  minor  frame  of  the  data 

START  BIT 

Required  when:  Allowed 

used  in  the  CRC  calculation. 

Range:  1  to  the  value  of  P-d\ME2 

CRC  DATA 

P-d\CRCDN 

Allowed  when: 

When  P-d\CRC  is  not  N 

The  number  of  data  bits  used  in  the  CRC  calculation. 

NUMBER  OE  BITS 

Required  when:  Allowed 

The  data  being  checked  may  span  2  minor  frames  but 

Range:  1  to  the  value  of  P-d\ME2 

is  never  longer  than  a  single  minor  frame.  Minor 
frame  fill  bits  are  never  used  as  part  of  a  CRC 
calculation. 

Minor  Frame 

NUMBER  OE 

P-d\MP\N 

R/R  Ch  10  Status:  RO-PAK 

Number  of  minor  frames  in  a  major  frame. 

MINOR  ERAMES 

Allowed  when:  P-d\DLN  is  specified 

IN  MAJOR  ERAME 

Required  when:  Allowed  and  defining 

CHIO  non-throughput  mode 

Range:  1  to  256 

Default:  1 

NUMBER  OE 

P-d\MPI 

R/R  Ch  10  Status:  RO-PAK 

Specify  the  number  of  words  in  a  minor  frame,  as 

WORDS  IN  A 

Allowed  when:  P-d\DLN  is  specified 

defined  in  Chapter  4,  Section  4.3  (the  minor  frame 

MINOR  ERAME 

Required  when:  Allowed  and  defining 

CHIO  non-throughput  mode 

synchronization  pattern  is  always  considered  as  one 
word,  regardless  of  its  length). 

Range:  2-4096 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

NUMBER  OF  BITS 
IN  A  MINOR 
FRAME 

P-d\MF2 

R/R  Ch  10  Status:  RO-PAK 

Allowed  when:  P-d\DEN  is  specified 
Required  when:  P-d\CRC  is  not  N  or 
defining  CHIO  non-throughput  mode 

Range:  20  to  16384 

Number  of  bits  in  a  minor  frame  including  minor  frame 
synchronization  pattern. 

SYNC  TYPE 

P-d\MF3 

Allowed  when:  P-d\DEN  is  specified 

Range:  Enumeration 

Define  minor  frame  synchronization  type. 

Enumeration 

Description 

FPT 

Fixed  pattern 

ACC 

Alternating  Code 
Complement 

OTH 

Other,  define  in  comments 

Default:  FPT 

Synchronization  Pattern 

EENGTH 

P-d\MF4 

R/R  Ch  10  Status:  RO-PAK 

Allowed  when:  P-d\DEN  is  specified 
Required  when:  Allowed  and  defining 

CHIO  non-throughput  mode 

Range:  16  to  33 

Specify  the  minor  frame  synchronization  pattern  length 
in  number  of  bits. 

PATTERN 

P-d\MF5 

R/R  Ch  10  Status:  RO-PAK 

Allowed  when:  P-d\DEN  is  specified 
Required  when:  Allowed  and  defining 

CHIO  non-throughput  mode 

Range:  The  value  of  MF4  count  of  binary 
pattern 

Define  minor  frame  synchronization  pattern  in  bits  (Is 
and  Os)  with  the  left-most  bit  as  the  first  bit 
transmitted.  “X”  may  be  used  to  indicate  a  “don’t 
care”  bit. 

Synchronization  Criteria 

IN-SYNC 

CRITERIA 

P-d\SYNCI 

Allowed  when:  P-d\DEN  is  specified 

Range:  0  to  99  or  NS 

Default:  NS 

This  specifies  the  desired  criteria  for  declaring  the 
system  to  be  in  sync.  “0”  (First  good  sync).  Number 
of  good  sync  patterns  (1  or  greater).  “NS”  (Not 
specified). 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

SYNC  PATTERN 
CRITERIA 

P-d\SYNC2 

Allowed  when:  P-d\SYNCl  is  not  NS 

Number  of  bits  that  may  be  in  error  in  the 
synchronization  pattern 

Required  when:  Allowed 

Range:  0  to  the  value  of  P-d\MF4 

Out  of  Synchronization  Criteria 

NUMBER  OF 
DISAGREES 

P-d\SYNC3 

Allowed  when:  P-d\DEN  is  specified 

Specify  the  desired  criteria  for  declaring  the  system  out 
of  sync.  Number  of  bad  sync  patterns,  (1  or  greater). 
“NS”  (Not  specified). 

Range:  0  to  99  or  NS 

Default:  NS 

SYNC  PATTERN 
CRITERIA 

P-d\SYNC4 

Allowed  when:  P-d\SYNC3  is  not  NS 

Number  of  bits  that  may  be  in  error  in  the 
synchronization  pattern. 

Required  when:  Allowed 

Range:  0  to  the  value  of  P-d\MF4 

FIFE  BITS 

P-d\SYNC5 

Allowed  when:  P-d\DEN  is  specified  and 
defining  CHIO  non-throughput  mode 

Max  number  of  fill  bits  between  end  of  frame  and  next 
sync  pattern  that  can  be  ignored. 

Range: 0-16384 

Default:  0 

Minor  Frame  Format  Definition 

NUMBER  OF 
UNIQUE  WORD 
SIZES 


P-d\MFW\N 


R/R  Ch  10  Status:  RO-PAK 


Allowed  when:  P-d\DEN  is  specified  and 
words  are  sized  other  than  the  default  word 
size 


Required  when:  Allowed  and  defining 
CHIP  non-throughput  mode 


Range:  0-value  of  P-d\MFl-l 


Count  of  words  that  are  not  the  default  word  size 


WORD  NUMBER 


P-d\MFWl-n 


R/R  Ch  10  Status:  RO-PAK 


Allowed  when:  P-d\DEN  is  specified  and 
words  are  sized  other  than  the  default  word 
size 


Word  position  in  the  minor  frame.  Word  position  1 
follows  the  synchronization  pattern. 


Required  when:  Allowed  and  defining 
CHIP  non-throughput  mode 


Range:  1-value  ofP-d\MFl-l 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 


Parameter 


Code  Name 


Usage  Attributes 


Definition 


NUMBER  OF  BITS 
IN  WORD 


P-d\MFW2-n 


R/R  Ch  10  Status:  RO-PAK 


Allowed  when:  P-d\MFW I  is  specified 
Required  when:  Allowed 


The  number  of  bits  in  word  position  defined  by  P- 
d\MFWl-n.  If  default  value,  do  not  include. 


Range:  4-64 


NOTE:  The  above  pair  set  must  be  defined  for  all  words  that  have  a  length  other  than  the  common  word  length.  Therefore,  all  word  positions  not 
included  in  the  above  will  have  the  common  word  length  as  a  default  value. 


Subframe  Synchronization 


NUMBER  OF 
SUBFRAME  ID 
:OUNTERS 


P-d\ISF\N 


R/R  Ch  10  Status:  RO-PAK 


Allowed  when:  P-d\DFN  is  specified 


Range:  0-10 


Default:  0 


Specify  the  number  of  subframe  ID  counters  defined 
within  the  minor  frame. 


SUBFRAME  ID 
COUNTER  NAME 


P-d\ISFl-n 


R/R  Ch  10  Status:  RO-PAK 


Specify  the  subframe  ID  counter  name. 


Allowed  when:  P-d\ISF\N  is  greater  than  0 


Required  when:  P-d\ISF\N  is  greater  than  1 
Range:  32  characters 


SUBFRAME  SYNC 
TYPE 


P-d\ISF2-n 


R/R  Ch  10  Status:  RO-PAK 


Define  the  subframe  synchronization  type. 


Allowed  when:  P-d\ISF\N  is  greater  than  0 
Range:  Enumeration 


Enumeration 


ID 


OT 


Description 


ID  counter 


Other,  define  in  comments 


Default:  ID 


ID  Counter 


SUBFRAME  ID 

COUNTER 

EOCATION 


P-d\IDCl-n 


R/R  Ch  10  Status:  RO-PAK 


Allowed  when:  P-d\ISF\N  is  greater  than  0 
Required  when:  Allowed  and  defining 
CHIP  non-throughput  mode 


Range:  1  to  value  of  P-d\MFl-l 


If  ID  counter  is  designated  as  the  subframe  sync  type, 
give  the  minor  frame  word  position  of  the  counter. 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

ID  COUNTER  MSB 
STARTING  BIT 
LOCATION 

P-d\IDC3-n 

R/R  Ch  10  Status:  RO-PAK 

Specify  the  bit  location  of  the  ID  counter  msb  within 
the  word. 

Allowed  when:  P-d\ISP\N  is  greater  than  0 

Required  when:  Allowed  and  defining 

CHIO  non-throughput  mode 

Range:  1  to  size  of  word  (either  P- 
d\MPW2-n  or  P-d\Pl) 

ID  COUNTER 
LENGTH 

P-d\IDC4-n 

R/R  Ch  10  Status:  RO-PAK 

Specify  the  subframe  ID  counter  length,  number  of 
bits. 

Allowed  when:  P-d\ISP\N  is  greater  than  0 

Required  when:  Allowed 

Range:  1  to  size  of  word  (either  P- 
d\MPW2-n  or  P-d\Pl) 

ID  COUNTER 
TRANSEER 

ORDER 

P-d\IDC5-n 

R/R  Ch  10  Status:  RO-PAK 

Specify  whether  the  msb  or  Isb  is  transferred  first. 

Allowed  when:  P-d\ISP\N  is  greater  than  0 

Range:  Enumeration 

Enumeration 

Description 

M 

msb 

L 

Isb 

D 

As  specified  in  WORD 
TRANSEER  ORDER  (P- 
d\E2). 

Default:  D 

ID  COUNTER 
INITIAL  VALUE 

P-d\IDC6-n 

R/R  Ch  10  Status:  RO-PAK 

Specify  the  initial  value  of  the  ID  counter. 

Allowed  when:  P-d\ISP\N  is  greater  than  0 

Required  when:  Allowed 

Range:  0,  1,  number  of  minor  frames- 1, 
number  of  minor  frames 

INITIAL  COUNT 
MINOR  ERAME 
NUMBER 

P-d\IDC7-n 

R/R  Ch  10  Status:  RO-PAK 

Specify  the  minor  frame  number  associated  with  the 
initial  count  value. 

Allowed  when:  P-d\ISP\N  is  greater  than  0 

Range:  1 

Default:  1 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

ID  COUNTER  END 
VAEUE 

P-d\IDC8-n 

R/R  Ch  10  Status:  RO-PAK 

Allowed  when:  P-d\ISP\N  is  greater  than  0 
Required  when:  Allowed 

Range:  0,1, number  of  minor  frames- 1, 
number  of  minor  frames 

Specify  the  end  value  of  the  ID  counter. 

END  COUNT 
MINOR  ERAME 
NUMBER 

P-d\IDC9-n 

R/R  Ch  10  Status:  RO-PAK 

Allowed  when:  P-d\ISP\N  is  greater  than  0 
Range:  Number  of  minor  frames 

Specify  the  minor  frame  number  associated  with  the 
end  count  value. 

COUNT 

DIRECTION 

P-d\IDC10-n 

R/R  Ch  10  Status:  RO-PAK 

Allowed  when:  P-d\ISP\N  is  greater  than  0 
Range:  Enumeration 

Specify  the  direction  of  the  count  increment. 

Enumeration 

Description 

INC 

Increasing 

DEC 

Decreasing 

Default:  INC 

Asynchronous  Embedded  Format 

NUMBER  OE 
ASYNCHRONOUS 
EMBEDDED 
EORMATS 

P-d\AEP\N 

Allowed  when:  P-d\DEN  specified 

Range:  0  to  99 

Default:  0 

Specify  the  number  of  asynchronous  embedded 
formats. 

DATA  EINK 

NAME 

P-d\AEP\DEN-n 

Allowed  when:  P-d\AEE\N  is  greater  than  0 
Required  when:  Allowed 

Einks  to:  P-d\DEN 

Range:  32  characters 

Provide  the  data  link  name  for  this  asynchronous 
embedded  format.  Repeat  name  and  the  following 
entries  for  the  second  format,  as  appropriate.  A 
separate  data  link  definition  must  be  provided  for  each 
asynchronous  embedded  format. 

SUPERCOM 

P-d\AEPl-n 

Allowed  when:  P-d\AEE\N  is  greater  than  0 
Required  when:  Allowed 

Range:  1  to  P-d\MEl-l  or  NO 

If  the  asynchronous  format  is  not  supercommutated, 
enter  “NO”.  Otherwise,  enter  the  number  of  host 
minor  frame  words  that  are  used. 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

LOCATION 

DEFINITION 

P-d\AEF2-n 

Allowed  when:  P-d\AEF\N  is  greater  than  0 

If  supercommutated,  specify  how  the  word  locations 
are  defined. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

El 

First  word  and  interval 

EL 

Every  location 

CW 

Contiguous  words 

NA 

Not  applicable 

LOCATION 

P-d\AEF3-n-w 

Allowed  when:  ^ 

^-d\AEF\N  is  greater  than  0 

Specify  the  first  word  within  the  minor  frame  that 
contains  the  asynchronous  embedded  format  identified. 
For  the  method  when  every  word  location  is  defined, 
repeat  this  entry  for  each  word  position  applicable.  For 
the  first  word  and  interval  method,  include  the  next 
entry  to  define  the  interval. 

Required  when:  Allowed 

Range:  1  to  value  of  P-d\MFl-l 

INTERVAL 

P-d\AEF4-n 

Allowed  when:  P-d\AEF2-n  is  FI 

Specify  the  interval  to  be  used  to  define  the 
asynchronous  embedded  format  locations. 

Required  when:  Allowed 

Range:  1  to  value  of  P-d\MFl-l 

WORD  LENGTH 

P-d\AEF5-n-w 

Allowed  when:  P-d\AEF\N  is  greater  than  0 

Specify  the  number  of  embedded  bits  in  this  host  word 
location. 

Required  when:  Allowed 

Range:  1  to  size  of  word  (either  P- 
d\MFW2-n  or  P-d\Fl) 

MASK 

P-d\AEF6-n-w 

Allowed  when:  P-d\AEF\N  is  greater  than  0 

If  the  asynchronous  portion  of  the  word  is  shorter  than 
the  word  length,  then  provide  the  binary  mask  required 
to  indicate  which  bits  are  used  (Is  used.  Os  not  used). 
Left- most  bit  corresponds  to  the  msb. 

Required  when:  P-d\AEF5-n-w  is  not  the 
full  word  length 

Range:  1  to  size  of  word  (either  P- 
d\MFW2-n  or  P-d\Fl)  of  0,1 

SUB¬ 

COMMUTATED 

P-d\AEF7-n-w 

Allowed  when:  P-d\AEF\N  is  greater  than  0 

If  this  embedded  format  is  not  subcommutated  (and 
appears  in  every  minor  frame),  enter  “NO”;  otherwise, 
enter  the  number  of  definitions  to  follow,  m. 

Range:  0  to  size  of  minor  frame  length  or 

NO 

Default:  NO 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

START  FRAME 

P-d\AEF8-n-w-m 

Allowed  when:  P-d\AEF7-n-w  is  not  NO 

When  the  embedded  format  is  subcommutated,  enter 
the  first  minor  frame  number  this  embedded  format 
appears  in.  If  this  field  is  missing,  the  default  value 
“1”  is  assumed.  Repeat  P-d\AEF7-n-w  number  of 
times. 

Range:  1  to  size  of  minor  frame  length 

Default:  1 

FRAME 

INTERVAE 

P-d\AEF9-n-w-m 

Allowed  when:  P-d\AEF7-n-w  is  not  NO 

When  the  embedded  format  is  subcommutated,  enter 
the  interval  between  minor  frames  that  this  embedded 
format  appears  in.  If  this  field  is  missing,  the  default 
value  “1”  is  assumed.  Repeat  P-d\AEF7-n-w  number 
of  times. 

Range:  0  to  size  of  minor  frame  length 

Default:  1 

Format  Change 

Frame  Format  Identifier 

EOCATION 

P-d\FFIl 

Allowed  when:  P-d\DEN  is  specified 

Specify  the  position  in  the  minor  frame  that  contains 
the  frame  format  identification  (FFI)  word.  If  more 
than  one  word  location,  provide  the  details  in  the 
comments. 

Range:  1  to  value  of  P-d\MFl-l 

MASK 

P-d\FFI2 

Allowed  when:  P-d\FFIl  is  specified 

If  the  FFI  is  shorter  than  the  word  length,  then  provide 
the  binary  mask  required  to  indicate  which  bits  are 
used.  Eeftmost  bit  corresponds  to  the  msb. 

Required  when:  Allowed 

Range:  1  to  size  of  word  (either  P- 
d\MFW2-n  or  P-d\Fl)  of  0,1 

Measurement  List  Change 

NUMBER  OF 

MEASUREMENT 

FISTS 

P-d\MEC\N 

Allowed  when:  If  P-d\FSC\N  is  0 

Specify  the  number  of  measurement  lists  that  are 
required  to  be  selected.  If  none,  enter  “NO”. 

Otherwise,  enter  the  number,  n. 

Range:  1-99,  NO 

Default:  NO 

FFI  PATTERN 

P-d\MECl-n 

Allowed  when:  P-d\MEC\N  is  not  NO 

Specify  the  FFI  pattern  that  corresponds  to  the 
measurement  list  (Is  and  Os).  This  entry  and  the  next 
are  an  ordered  pair. 

Required  when:  Allowed 

Range:  Size  of  1-Size  of  word  (either  P- 
d\MFW2-n  or  P-d\Fl)  of  0,1 

MEASUREMENT 
FIST  NAME 

P-d\MEC2-n 

Allowed  when:  P-d\MEC\N  is  not  NO 

Specify  the  measurement  list  name. 

Required  when:  Allowed 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Finks  to:  D-x\MFN-y 

Range:  32  characters 

Format  Structure  Change 

NUMBER  OF 
FORMATS 

P-d\FSC\N 

Allowed  when:  P-d\MFC\N  is  NO 

Specify  the  number  of  formats  to  be  defined. 

Range:  0-99 

Default:  0 

FFI  PATTERN 

P-d\FSCl-n 

Allowed  when:  P-d\FSC\N  is  specified 

Specify  the  FFI  pattern  that  corresponds  to  the  format 
that  is  defined.  This  entry  and  the  next  are  an  ordered 
pair. 

Required  when:  Allowed 

Range:  Size  of  1-Size  of  word  (either  P- 
d\MFW2-n  or  P-d\Fl)  of  0,1 

DATA  FINK  ID 

P-d\FSC2-n 

Allowed  when:  P-d\FSC\N  is  specified 

Identify  the  format  that  corresponds  to  this  FFI  code. 

Required  when:  Allowed 

Finks  to:  P-d\DFN 

Range:  32  characters 

Alternate  Tag  And  Data 

NUMBER  OF 

TAGS 

P-d\AFT\N 

Allowed  when:  P-d\DFN  specified 

Specify  the  number  of  tag/data  pairs  to  be  included 
within  the  minor  frame. 

Range:  0-999 

Default:  0 

NUMBER  OF  BITS 
IN  TAG 

P-d\AFTl 

Allowed  when:  if  P-d\AFT\N  is  greater 
than  0 

Specify  the  number  of  bits  that  are  in  the  tag. 

Required  when:  Allowed 

Range:  Range  1-Size  of  word  (P-d\Fl) 

NUMBER  OF  BITS 
IN  DATA  WORD 

P-d\AFT2 

Allowed  when:  if  P-d\AFT\N  is  greater 
than  0 

Specify  the  number  of  bits  that  are  in  the  common  data 
word. 

Required  when:  Allowed 

Range:  Range  1-Size  of  word  (P-d\Fl) 

FIRST  TAG 
FOCATION 

P-d\AFT3 

Allowed  when:  if  P-d\AFT\N  is  greater 
than  0 

Identify  the  location  of  the  start  of  the  first  tag  location 
in  terms  of  bits,  with  the  first  bit  position  after  the 
synchronization  pattern  being  number  1 . 

Required  when:  Allowed 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Range:  1-16384 

SEQUENCE 

P-d\AET4 

Allowed  when:  if  P-d\AET\N  is  greater 
than  0 

If  the  tag/data  word  sequence  is  tag,  then  data  enter 
“N”  for  normal.  If  the  data  precedes  the  tag,  enter  “R” 
for  reversed. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

N 

Normal 

R 

Reversed 

Asynchronous  Data  Merge  Format 

NUMBER  OE 
ASYNCHRONOUS 
DATA  MERGE 
EORMATS 

P-d\ADM\N 

Allowed  when:  P-d\DEN  specified 

Specify  the  number  of  asynchronous  data  merge 
formats. 

Range:  0-99 

Default:  0 

DATA  MERGE 
NAME 

P-d\ADM\DMN-n 

Allowed  when:  P-d\ADM\N  is  not  0 

Provide  the  data  merge  name  for  this  asynchronous 
data  merge  format.  This  can  be  used  to  identify  the 
source  of  the  data  merge  format,  as  appropriate.  Use 
the  comments  field  to  describe  this  data  source  for  the 
asynchronous  data  merge  format. 

Required  when:  Allowed 

Einks  to:  P-d\DEN 

Range:  32  characters 

MASK  AND 
PATTERN 

P-d\ADM\MP-n 

Allowed  when:  P-d\ADM\N  is  not  0 

If  the  asynchronous  data  merge  format  uses  the 
overhead  bits  as  recommended  in  Chapter  4,  enter  “N”. 
Otherwise  enter  “Y”  and  specify  the  overhead  mask 
and  patterns.  Default  is  “N”  (Chapter  4). 

Range:  Enumeration 

Enumeration 

Description 

N 

No 

Y 

Yes 

Default:  N 

OVERHEAD 

MASK 

P-d\ADM\OHM-n 

Allowed  when:  P-d\ADM\MP-n  is  Y 

If  “MASK  AND  PATTERN”  is  “Y”,  provide  the  mask 
of  the  overhead  bits  in  binary.  Eeft-most  bit 
corresponds  to  the  msb. 

Required  when:  Allowed 

Range:  Size  of  1-Size  of  word  (either  P- 
d\MEW2-n  or  P-d\Pl)  of  0,1 

ERESH  DATA 
PATTERN 

P-d\ADM\EDP-n 

Allowed  when:  P-d\ADM\MP-n  is  Y 

If  “MASK  AND  PATTERN”  is  “Y”,  provide  the 
pattern  for  fresh  data  in  binary.  Eeft-most  bit 

Required  when:  Allowed 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Range:  Size  of  1-Size  of  word  (either  P- 
d\MFW2-n  or  P-d\Fl)  of  0,1 

corresponds  to  the  msb. 

DATA 

P-d\ADM\DOP-n 

Allowed  when:  P-d\ADM\MP-n  is  Y 

If  “MASK  AND  PATTERN”  is  “Y”,  provide  the 

OVERFLOW 

Required  when:  Allowed 

pattern  for  data  overflow  in  binary.  Left-most  bit 

PATTERN 

Range:  Size  of  1-Size  of  word  (either  P- 
d\MFW2-n  or  P-d\Fl)  of  0,1 

corresponds  to  the  msb. 

STALE  DATA 

P-d\ADM\SDP-n 

Allowed  when:  P-d\ADM\MP-n  is  Y 

If  “MASK  AND  PATTERN”  is  “Y”,  provide  the 

PATTERN 

Required  when:  Allowed 

pattern  for  stale  data  in  binary.  Left-most  bit 

Range:  Size  of  1-Size  of  word  (either  P- 
d\MFW2-n  or  P-d\Fl)  of  0,1 

corresponds  to  the  msb. 

USER  DEFINED 

P-d\ADM\UDP-n 

Allowed  when:  P-d\ADM\MP-n  is  Y 

If  “MASK  AND  PATTERN”  is  “Y”,  provide  the 

PATTERN 

Required  when:  Allowed 

pattern  for  user  defined  in  binary.  Left-most  bit 

Range:  Size  of  1-Size  of  word  (either  P- 
d\MFW2-n  or  P-d\Fl)  of  0,1 

corresponds  to  the  msb. 

SUPERCOM 

P-d\ADMl-n 

Allowed  when:  P-d\ADM\N  is  not  0 

If  the  asynchronous  data  merge  format  is  not  super- 

Required  when:  Allowed 

commutated,  enter  “NO”.  Otherwise,  enter  the  number 

Range:  Range  of  l-P-d\MFl-l  or  NO 

of  host  minor  frame  words  that  are  used. 

LOCATION 

P-d\ADM2-n 

Allowed  when:  P-d\ADM\N  is  not  0 

If  supercommutated,  specify  how  the  word  locations 

DEFINITION 

Required  when:  Allowed 

are  defined. 

Range:  Enumeration 

Enumeration 

Description 

FI 

First  word  and  interval 

EL 

Every  location 

CW 

Contiguous  words 

NA 

Not  applicable 

LOCATION 

P-d\ADM3-n-w 

Allowed  when:  ^ 

P-d\ADM\N  is  not  0 

Specify  the  first  word  within  the  minor  frame  that 

Required  when:  Allowed 

contains  the  asynchronous  data  merge  format 
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Table  9-6.  PCM  Format  Attributes  Group  (P) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Range:  Range  of  l-value  of  P-d\MPl-l 

identified.  Por  the  method  when  every  word  location  is 
defined,  repeat  this  entry  for  each  word  position 
applicable.  Por  the  first  word  and  interval  method, 
include  the  next  entry  to  define  the  interval. 

INTERVAL 

P-d\ADM4-n 

Allowed  when:  If  P-d\ADM2-n  is  PI 

Specify  the  interval  to  be  used  to  define  the 

Required  when:  Allowed 

asynchronous  data  merge  format  locations. 

Range:  Range  of  0-value  of  P-d\MPl-l 

DATA  LENGTH 

P-d\ADM5-n 

Allowed  when:  P-d\ADM\N  is  not  0 

Specify  the  number  of  data  bits  used  in  this  data  merge 

Required  when:  Allowed 

format. 

Range:  1-Size  of  word  (P-d\Pl) 

MSB  LOCATION 

P-d\ADM6-n 

Allowed  when:  P-d\ADM\N  is  not  0 

Provide  the  msb  position  within  the  host  minor  frame 

Required  when:  Allowed 

location. 

Range:  1-Size  of  word  (P-d\Pl) 

PARITY 

P-d\ADM7-n 

Allowed  when:  P-d\ADM\N  is  not  0 

If  used,  specify  the  parity  information. 

Range:  Enumeration 

Enumeration 

Description 

EV 

Even 

OD 

Odd 

NO 

None 

Default:  NO 

SUB- 

P-d\ADM8-n-w 

Allowed  when:  P-d\ADM\N  is  not  0 

If  this  data  merge  format  is  not  subcommutated  (and 

COMMUTATED 

Range:  Range  0-size  of  subframe,  NO 

appears  in  every  minor  frame),  enter  “NO”;  otherwise. 

Default:  NO 

enter  the  number  of  definitions  to  follow,  m. 

START  LRAME 

P-d\ADM9-n-w-m 

Allowed  when:  P-d\ADM8-n-w  is  not  NO 

When  the  data  merge  format  is  subcommutated,  enter 

Range:  1-size  of  subframe 

the  first  minor  frame  number  this  data  merge  format 

Default:  1 

appears  in.  If  this  field  is  missing,  the  default  value 
“1”  is  assumed.  Repeat  m  number  of  times. 

LRAME 

P-d\ADM10-n-w- 

Allowed  when:  P-d\ADM8-n-w  is  not  NO 

When  the  data  merge  format  is  subcommutated,  enter 

INTERVAL 

m 

Range:  0-size  of  subframe 

the  interval  between  minor  frames  that  this  data  merge 
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Parameter 

Code  Name 

Usage  Attributes 

Definition 

Default:  1 

format  appears  in.  If  this  field  is  missing,  the  default 
value  “1”  is  assumed.  Repeat  m  number  of  times. 

Chapter  7  Format 

r^APTER  7 
NUMBER  OE 
SEGMENTS 

P-d\C7\N 

R/R  Ch  10  Status:  RO 

If  a  Chapter  7  stream  is  defined,  specify  the  number  of 
Chapter  7  segments  to  be  defined. 

Allowed  when:  P-d\DEN  is  specified 

Required  when:  Defining  a  Chapter  7 
stream 

Range:  0  to  the  value  of  P-d\MEl-l 

Default:  0 

CHAPTER  7  EIRST 
WORD  OE 
SEGMENT 

P-d\C7EW-n 

R/R  Ch  10  Status:  RO 

Specify  the  starting  PCM  word  of  the  Chapter  7 
segment.  The  first  transmitted  bit  of  this  word  is  the 
first  bit  of  the  segment. 

Allowed  when:  P-d\C7\N  is  not  0 

Required  when:  Allowed 

Range:  1  to  the  value  of  P-d\MEl-l 

CHAPTER  7 
NUMBER  OE  PCM 
WORDS  IN 
SEGMENT 

P-d\C7NW-n 

R/R  Ch  10  Status:  RO 

Specify  the  number  of  PCM  words  used  that  the 

Chapter  7  segment  occupies.  An  integral,  packed 
number  of  Chapter  7  bytes  is  used.  Any  left-over  (0-7) 
bits  are  ignored  at  the  end. 

Allowed  when:  P-d\C7\N  is  not  0 

Required  when:  Allowed 

Range:  1  to  the  value  of  P-d\MEl-l 

Comments 

COMMENTS 

P-d\COM 

Allowed  when:  defining  PCM  Data 

Provide  the  additional  information  requested  or  any 
other  information  desired. 

9-109 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  9,  July  2017 


b.  PCM  Measurement  Description  Group  (D).  Figure  9-7  and  Table  9-7  eontain  the  PCM 
measurement  deseriptions.  The  deseriptions  define  eaeh  measurand  or  data  item  of 
interest  within  the  frame  format  speeified  in  the  PCM  attributes.  Table  9-7  ineludes  the 
measurement  name,  whieh  links  the  measurement  to  the  Data  Conversion  Attributes 
group. 


NOTE 


y 


Beginning  with  RCC  IRIG  106-09,  it  is  reeommended  that  the  “Word  and 
Frame”  location  type  be  used  instead  of  the  other  six  traditional  location 
types.  Additionally,  when  using  Word  and  Frame,  it  is  recommended  to 
avoid  the  use  of  subframes  (as  defined  in  the  Subframe  Definitions  section  of 
the  PCM  Format  Attributes  group  in  RCC  IRIG  106-09  and  previous 
releases)  and  locate  measurements  by  word  number  and  frame  number  within 
the  major  frame.  As  of  the  release  of  RCC  IRIG  106- 1 1,  the  other  six 
location  types  and  subframes  have  been  removed. 


Figure  9-7. 

PCM  Measurement  Description  Group  (D) 

Code  Name 

DATA  LINK  NAME 

-9-II2 

(D-x\DEN) 

NUMBER  OF  MEASUREMENT  EISTS 

(D-x\ME\N) 

MEASUREMENT  EIST  NAME 

(D-x\MEN-y) 
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(D-x\MN\N-y) 
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MEASUREMENT  NAME 
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PARITY 

(D-x\MNI-y-n) 

PARITY  TRANSEER  ORDER 

(D-x\MN2-y-n) 

MEASUREMENT  TRANSEER  ORDER 

(D-x\MN3-y-n) 

9-113 

leasurement  Location 

MEASUREMENT  EOCATION  TYPE 

(D-x\ET-y-n) 

*Word  And  Frame 

SUBFRAME  ID  COUNTER  NAME 

(D-xMDCN-y-n) 

NUMBER  OF  MEASUREMENT  EOCATIONS 

(D-x\MME\N-y-n) 

NUMBER  OF  FRAGMENTS 

(D-x\MNF\N-y-n-m) 

WORD  POSITION 

(D-x\WP-y-n-m-e) 

WORD  INTERVAE 

(D-x\WTy-n-m-e) 
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FRAME  POSITION 

(D-x\FP-y-n-m-e) 

FRAME  INTERVAE 

(D-x\FI-y-n-m-e) 

BIT  MASK 

(D-x\WFM-y-n-m-e) 
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(D-x\WFT-y-n-m-e) 

FRAGMENT  POSITION 
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*  Simultaneous  Sampling 

SAMPEING  MODE 

(D-x\SS-y-n) 

SAMPEE  ON 

(D-x\SON-y-n) 

SAMPEE  ON  MEASUREMENT  NAME 

(D-x\SMN-y-n) 

NUMBER  OF  WORD  FRAME  SAMPEES 

(D-x\SS\N-y-n) 

SAMPEE  ON  WORD 

(D-x\SSI-y-n-s) 

SAMPEE  ON  FRAME 

(D-x\SS2-y-n-s) 

OR 

*  Tagged  Data 

NUMBER  OF  TAG  DEFINITIONS 

(D-x\TD\N-y-n) 
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TAG  NUMBER 

(D-x\TD2-y-n-m) 

BIT  MASK 

(D-x\TD3-y-n-m) 

ERAGMENT  TRANSEER  ORDER 

(D-x\TD4-y-n-m) 

ERAGMENT  POSITION 

(D-x\TD5-y-n-m) 

*Relative 

NUMBER  OE  PARENT  MEASUREMENTS 

(D-x\REE\N-y-n) 

PARENT  MEASUREMENT 

(D-x\REE  1 -y-n-m) 

BIT  MASK 

(D-x\REE2-y-n-m) 

ERAGMENT  TRANSEER  ORDER 

(D-x\REE3-y-n-m) 

ERAGMENT  POSITION 

(D-x\REE4-y-n-m) 

*  Comments 
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COMMENTS 

(D-x\COM) 

*Heading  Only  -  No  Data  Entry 
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Table  9-7.  PCM  Measurement  Description  Group  (D) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

DATA  LINK 

NAME 

D-x\DEN 

Allowed  when:  P-d\DEN  is  specified  and 
decommutation  is  required 

Provide  the  data  link  name. 

Required  when:  Allowed  and  defining  CHIO 
non-throughput  mode 

Einks  from:  P-d\DEN 

Range:  32  characters 

NUMBER  OE 

MEASUREMENT 

EISTS 

D-x\ME\N 

Allowed  when:  D-x\DEN  is  specified 

Specify  the  number  of  measurement  lists  to  be 
provided. 

Required  when:  Allowed 

Range:  1-99 

MEASUREMENT 
EIST  NAME 

D-x\MEN-y 

Allowed  when:  D-x\DEN  is  specified 

Provide  the  measurement  list  name  associated  with  the 
following  attributes.  The  following  information  will 
have  to  be  repeated  for  each  measurement  list 
identified  in  the  PCM  Eormat  Attributes  group. 

Required  when:  Allowed 

Einks  from:  P-d\MEC2-n 

Range:  32  characters 

NUMBER  OE 
MEASURANDS 

D-x\MN\N-y 

Allowed  when:  D-x\DEN  is  specified 

Specify  the  number  of  measurands  included  within 
this  measurement  list. 

Required  when:  Allowed 

Range:  1-9999999 

MEASUREMENT 

NAME 

D-x\MN-y-n 

Allowed  when:  D-x\DEN  is  specified 

Measurand  name. 

Required  when:  Allowed 

Einks  to:  C-d\DCN 

Einks  from:  D-x\REEl-y-n-m,  R-x\SME\SMN- 
n-m 

Range:  32  characters 

PARITY 

D-x\MNl-y-n 

Allowed  when:  D-x\DEN  is  specified 

Specify  parity. 

Range:  Enumeration 

Enumeration 

Description 

EV 

Even 

OD 

Odd 

NO 

None 
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Table  9-7.  PCM  Measurement  Description  Group  (D) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

DE 

Minor  frame  default,  as 
specified  in  PARITY  (P-d\P3) 

Default:  DE 

PARITY 

TRANSFER 

ORDER 

D-x\MN2-y-n 

Allowed  when:  D-x\MNl-y-n  is  not  NO 

Parity  bit  location. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

E 

Eeads  measurement 

T 

Trails  measurement 

D 

Minor  frame  default,  as 
specified  in  PARITY 
TRANSEER  ORDER  (P-d\E4) 

MEASUREMENT 

TRANSEER 

ORDER 

D-x\MN3-y-n 

Allowed  when:  D-x\DEN  specified 

Measurement  transfer  order  bit  location. 

Range:  Enumeration 

Enumeration 

Description 

M 

msb  first 

E 

Isb  first 

D 

Default,  as  specified  in  WORD 
TRANSEER  ORDER,  (P-d\E2) 

Default:  D 

Measurement  Location 

MEASUREMENT 
EOCATION  TYPE 

D-x\ET-y-n 

Allowed  when:  D-x\DEN  specified 

Specify  the  nature  of  the  location  of  this  measurand. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

WDER 

Word  and  frame 

TD 

Tagged  data 

REE 

Relative 
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Table  9-7.  PCM  Measurement  Description  Group  (D) 


Parameter 


Code  Name 


Usage  Attributes 


Definition 


Word  And  Frame 


SUBFRAME  ID 
COUNTER  NAME 


D-x\IDCN-y-n 


Allowed  when:  D\ET  is  “WDER” 


Required  when:  Allowed 


Range:  32  characters 


Required  condition:  When  P\ISE\N  >  1 


Specify  the  subframe  ID  counter  name  (ISEl)  that 
applies  to  this  measurement  (needed  only  if  the  PCM 
format  contains  multiple  ID  counters). 


NUMBER  OE 

MEASUREMENT 

EOCATIONS 


D-x\MME\N-y- 

n 


Allowed  when:  D\ET  is  “WDER’ 


Required  when:  Allowed 


Range:  1-9999 


Specify  the  number  of  location  definitions  to  follow 
for  this  measurement. 


NUMBER  OE 
ERAGMENTS 


D-x\MNE\N-y- 

n-m 


Allowed  when:  D\ET  is  “WDER’ 


Required  when:  Allowed 


Range:  1-8 


Number  of  word  positions  that  each  fragmented 
measurement  location  occupies.  Enter  “1”  if  this 
measurement  is  not  fragmented. 


WORD  POSITION 


D-x\WP-y-n-m- 

e 


Allowed  when:  D\ET  is  “WDER’ 


Required  when:  Allowed 


Range:  1  -  (P\ME1-1) 


Specify  the  minor  frame  word  position  of  this 
measurement  location  or  fragment. 


WORD 

INTERVAE 


D-x\WTy-n-m-e 


Allowed  when:  D\ET  is  “WDER” 


Range:  0  -  (P\MEl-2) 


Default:  0 


Specify  the  interval  that  is  the  offset  from  the  first 
word  position  and  each  subsequent  word  position.  An 
interval  of  zero  indicates  that  there  is  only  one  word 
position  being  defined. 


ERAME  POSITION 


D-x\PP-y-n-m-e 


Allowed  when:  D\ET  is  “WDER” 


Range:  1  -  P\ME\N 


Default:  1 


Specify  the  frame  location  of  this  measurement 
location  or  fragment. 


ERAME 

INTERVAE 


D-x\EI-y-n-m-e 


Allowed  when:  D\ET  is  “WDER’ 


Range:  0  -  (P\ME\N-1) 


Default:  0 


Specify  the  interval  that  is  the  offset  from  the  first 
frame  location  and  each  subsequent  frame  location. 
An  interval  of  zero  indicates  that  there  is  only  one 
frame  location  being  defined. 


BIT  MASK 


D-x\WEM-y-n- 

m-e 


Allowed  when:  D\ET  is  “WDER’ 


Range:  1-64  of  0,1  or  EW 


Default:  EW 


Binary  string  of  Is  and  Os  to  identify  the  bit  locations 
used  in  each  measurement  location  or  fragment.  If  the 
full  word  is  used,  enter  “EW”.  Eeft-most  bit 
corresponds  to  the  msb. 
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Table  9-7.  PCM  Measurement  Description  Group  (D) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

FRAGMENT 

TRANSFER 

ORDER 

D-x\WFT-y-n- 

m-e 

Allowed  when 

D\MNF\N  >  1 

Measurement  Transfer  Order  bit  location. 

Range:  Enumeration 

Enumeration 

Description 

M 

msb  first 

L 

Isb  first 

D 

Default,  as  specified  in  WORD 
TRANSFER  ORDER  (P-d\F2) 

Default:  D 

FRAGMENT 

POSITION 

D-x\WFP-y-n- 

m-e 

Allowed  when:  DVMNFVN  >  1 

A  number  from  1  to  N  specifying  the  position  of  this 
fragment  within  the  reconstructed  binary  data  word.  1 
corresponds  to  the  most  significant  fragment.  Each 
fragment  position  from  1  to  N  must  be  specified  only 
once. 

Range:  1  -  D\MNF\N 

Default:  1 

NOTE:  Measurement  word  length,  fragment  transfer  order,  and  fragment  position  attributes  do  not  apply  when  the  “number  of  fragments” 

attribute  for  a  measurement  is  1 . 

Simultaneous  Sampling 

p^AMPLING 

D-x\SS-y-n 

Allowed  when:  D-x\DLN  is  specified 

Specify  the  sampling  mode.  Default  is  Normal. 

MODE 

Range:  Enumeration 

Enumeration 

Description 

N 

Normal 

SS 

Simultaneous  Sample 

Default:  N 

SAMPLE  ON 

D-x\SON-y-n 

Allowed  when:  D-x\SS-y-n  is  SS 

Specify  where  the  Simultaneous  Sample  occurs  in  the 

Required  when:  Allowed 

format. 

Range  Enumeration 

Choices  are  Measurement  Name,  Word/Frame,  On 

Enumeration 

Description 

Minor  Frame,  or  On  Major  Frame. 

MN 

Measurement 

WE 

Word/Frame 

MNF 

On  Minor  Frame 
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Table  9-7.  PCM  Measurement  Description  Group  (D) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

MJE 

On  Major  Erame 

SAMPLE  ON 

MEASUREMENT 

NAME 

D-x\SMN-y-n 

Allowed  when:  When  D-x\SON-y-n  is  MN 

Measurement  name  for  the  measurement  where  the 
simultaneous  sample  oeeurs. 

Required  when:  Allowed 

Range:  32  eharaeters 

NUMBER  OE 
WORD  ERAME 
SAMPEES 

D-x\SS\N-y-n 

Allowed  when:  D-x\SON-y-n  is  WE 

Number  of  Word/Erame  pairs  to  follow. 

Required  when:  Allowed 

Range:  Integer  O-i- 

SAMPEE  ON 

WORD 

D-x\SSl-y-n-s 

Allowed  when:  D-x\SON-y-n  is  WE 

Word  position  where  the  simultaneous  sample  oeeurs. 

Required  when:  Allowed 

Range:  1  -  the  value  of  P\ME1  -  1 

SAMPEE  ON 
ERAME 

D-x\SS2-y-n-s 

Allowed  when:  D-x\SON-y-n  is  WE 

Erame  position  where  the  simultaneous  sample  oeeurs. 
If  not  speeified,  then  simultaneous  sampling  oeeurs  on 
every  minor  frame. 

Range:  1  -(P\ME\N-1) 

Tagged  Data 

NUMBER  OE  TAG 
DEEINITIONS 

D-x\TD\N-y-n 

Allowed  when:  D\ET  is  “TD” 

Speeify  the  number  of  tag  definitions,  N.  If  not 
fragmented,  enter  “1”. 

Required  when:  Allowed 

Range:  1-9999 

TAG  NUMBER 

D-x\TD2-y-n-m 

Allowed  when:  D\ET  is  “TD” 

The  expeeted  tag  number  from  the  input  data  stream. 

Required  when:  Allowed 

Range:  1-9999999999 

BIT  MASK 

D-x\TD3-y-n-m 

Allowed  when:  D\ET  is  “TD” 

Binary  string  of  Is  and  Os  to  identify  the  bit  loeations 
in  a  word  position  that  are  assigned  to  this  tagged  data 
measurement.  If  the  full  word  is  used  for  this 
measurement,  enter  “EW”.  Eeft-most  bit  corresponds 
to  the  msb. 

Range:  1-64  of  0,1  or  EW 

Default:  EW 

ERAGMENT 

TRANSEER 

ORDER 

D-x\TD4-y-n-m 

Allowed  when:  D\ET  is  “TD” 

Eragment  Transfer  Order  bit  location. 

Range:  Enumeration 

Enumeration 

Deseription 

M 

msb  first 
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Table  9-7.  PCM  Measurement  Description  Group  (D) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

E 

Isb  first 

D 

Default,  as  specified  in  WORD 
TRANSEER  ORDER  (P-d\E2) 

Default:  D 

FRAGMENT 

POSITION 

D-x\TD5-y-n-m 

Allowed  when:  D\ET  is  “TD” 

A  number  from  1  to  N  specifying  the  position  of  this 
fragment  within  the  reconstituted  binary  data  word.  1 
corresponds  to  the  most  significant  fragment.  Each 
fragment  position  from  1  to  N  must  be  specified  only 
once. 

Range:  1  -  D\TD\N 

Default:  1 

Relative 

NUMBER  OE 
PARENT 

MEASUREMENTS 

D-x\REE\N-y-n 

Allowed  when:  D\ET  is  “REE” 

Specify  the  number  of  parent  measurements,  N.  If  not 
fragmented,  enter  “1”. 

Required  when:  Allowed 

Range:  1-9999999 

PARENT 

MEASUREMENT 

D-x\REEl-y-n- 

m 

Allowed  when:  D\ET  is  “REE” 

If  fragmented,  all  parent  measurements  must  be  at 
same  data  rate. 

Required  when:  Allowed 

Einks  to:  D-x\MN-y-n 

Range:  32  characters 

BIT  MASK 

D-x\REE2-y-n- 

m 

Allowed  when:  D\ET  is  “REE” 

Binary  string  of  Is  and  Os  to  identify  the  bit  locations 
in  a  word  position  that  are  assigned  to  this  relative 
measurement.  If  the  full  word  is  used  for  this 
measurement,  enter  “EW”.  Eeftmost  bit  corresponds 
to  the  msb. 

Range:  1-64  of  0,1  or  EW 

Default:  EW 

ERAGMENT 

TRANSEER 

ORDER 

D-x\REE3-y-n- 

m 

Allowed  when:  D\ET  is  “REE” 

Eragment  Transfer  Order  bit  location. 

Range:  Enumeration 

Enumeration 

Description 

M 

msb  first 

E 

Isb  first 

D 

Default,  as  specified  in  WORD 
TRANSEER  ORDER  (P-d\E2) 
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Table  9-7.  PCM  Measurement  Description  Group  (D) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Default:  D 

FRAGMENT 

POSITION 

D-x\REE4-y-n- 

m 

Allowed  when:  D\ET  is  “REE” 

A  number  from  1  to  N  specifying  the  position  of  this 
fragment  within  the  reconstituted  binary  data  word.  1 
corresponds  to  the  most  significant  fragment.  Each 
fragment  position  from  1  to  N  must  be  specified  only 
once. 

Range:  1-D\REE\N 

Default:  1 

Comments 

COMMENTS 

D-x\COM 

Allowed  when:  D-x\DEN  specified 

Provide  the  additional  information  requested  or  any 
other  information  desired. 

Range:  3200  characters 

NOTE:  This  group  will  contain  a  repetition  of  the  above  information  until  each  measurement  has  been  defined.  Any  word  position  not  included 
will  be  treated  as  a  spare  channel  or  a  “don’t  care”  channel.  Information  will  not  be  processed  for  these  “spare”  channels.  Note  that  measurement 
list  changes  and  format  changes  that  are  a  part  of  class  II  systems  are  included  in  the  above,  since  the  key  to  the  measurement  definition  is  the  data 
link  name  (format)  and  the  measurement  list. 
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c.  Bus  Data  Attributes  (B).  Figure  9-8  and  Table  9-8  describe  bus-originated  data  formats. 
The  Bus  Data  Attributes  group  defines  the  attributes  of  a  MIL-STD-1553  data  acquisition 
system  that  is  compliant  with  Chapter  8  or  an  ARINC  429  data  acquisition  system  that  is 
consistent  with  the  specification  of  ARINC  429  bus  data.  The  primary  components  of 
this  group  are  the  recording  description  and  message  content  definition.  The  former 
defines  the  method  by  which  the  data  were  recorded  on  the  tape  such  as  track  spread 
versus  composite.  The  latter  consists  of  the  message  identification  information  and  the 
measurement  description  set.  The  message  identification  information  defines  the 
contents  of  the  control  word  that  identifies  each  bus  message.  The  measurement 
description  set  describes  the  measurement  attributes  and  contains  the  measurement  name 
that  links  the  measurand  to  the  Data  Conversion  Attributes  group  (C). 

Mode  codes  are  described  in  the  message  identification  information.  If  the  Subterminal 
Address  field  contains  00000  or  11111,  the  information  in  the  Data  Word  Count/Mode 
Code  field  is  a  mode  code  and  identifies  the  function  of  the  mode  code.  If  the  mode  code 
has  associated  data  words,  they  are  described  in  this  section  of  the  attributes.  If  the  bus 
message  is  a  remote  terminal  to  remote  terminal  transfer,  both  the  transmit  command  and 
the  receive  command  are  used  to  identify  the  message. 


Figure  9-8. 

Bus  Data  Attributes  Group  (B) 

Code  Name 

DATA  LINK  NAME  -  9-121 

(B-x\DEN) 

TEST  ITEM 

(B-x\TA) 

BUS  PARITY 

(B-x\BP) 

NUMBER  OE  BUSES 

(B-x\NBS\N) 

BUS  NUMBER 

(B-x\BID-i) 

BUS  NAME 

(B-x\BNA-i) 

BUS  TYPE 

(B-x\BT-i) 

*  User-Defined  Words 

USER-DEEINED  WORD  I  MEASUREMENT 

(B-x\UMNI-i) 

PARITY 

(B-x\UIP-i) 

PARITY  TRANSEER  ORDER 

(B-x\UIPT-i) 

BIT  MASK 

(B-x\UlM-i) 

TRANSEER  ORDER 

(B-x\UIT-i) 

USER-DEEINED  WORD  2  MEASUREMENT 

(B-x\UMN2-i) 

PARITY 

(B-x\U2P-i) 

PARITY  TRANSEER  ORDER 

(B-x\U2PT-i) 

BIT  MASK 

(B-x\U2M-i) 

TRANSEER  ORDER 

(B-x\U2T-i) 

USER-DEEINED  WORD  3  MEASUREMENT 

(B-x\UMN3-i) 

PARITY 

(B-x\U3P-i) 

PARITY  TRANSEER  ORDER 

(B-x\U3PT-i) 

BIT  MASK 

(B-x\U3M-i) 

TRANSEER  ORDER 

(B-x\U3T-i) 

9-125 

^Recording  Description 

NUMBER  OE  TRACKS 

(B-x\TK\N-i) 

TRACK  SEQUENCE 

(B-x\TS-i-k) 

9-125 

^Message  Content  Definition 
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NU] 

VIBER  OE  MESSAGES 

(B-x\NMS\N-i) 

MESSAGE  NUMBER 

(B-x\MID-i-n) 

MESSAGE  NAME 

(B-x\MNA-i-n) 

COMMAND  WORD  ENTRY 

(B-x\CWE-i-n) 

COMMAND  WORD 

(B-x\CMD-i-n) 

REMOTE  TERMINAE  NAME 

(B-x\TRN-i-n) 

REMOTE  TERMINAE  ADDRESS 

(B-x\TRA-i-n) 

SUBTERMINAE  NAME 

(B-x\STN-i-n) 

SUBTERMINAE  ADDRESS 

(B-x\STA-i-n) 

TRANSMIT/RECEIVE  MODE 

(B-x\TRM-i-n) 

DATA  WORD  COUNT/MODE  CODE 

(B-x\DWC-i-n) 

SPECIAE  PROCESSING 

(B-x\SPR-i-n) 

9-127 

*AR] 

NC  429  Message  Definition 

ARINC  429  LABEL 

(B-x\LBL-i-n) 

ARINC  429  SDI  CODE 

(B-x\SDI-i-n) 

9-127 

*RT/RT  Receive  Command  List 

RECEIVE  COMMAND  WORD 
ENTRY 

(B-x\RCWE-i-n) 

RECEIVE  COMMAND  WORD 

(B-x\RCMD-i-n) 

REMOTE  TERMINAL  NAME 

(B-x\RTRN-i-n) 

REMOTE  TERMINAL  ADDRESS 

(B-x\RTRA-i-n) 

SUBTERMINAL  NAME 

(B-x\RSTN-i-n) 

SUBTERMINAL  ADDRESS 

(B-x\RSTA-i-n) 

DATA  WORD  COUNT 

(B-x\RDWC-i-n) 

9-128 

*Mode  Code 

MODE  CODE  DESCRIPTION 

(B-x\MCD-i-n) 

MODE  CODE  DATA  WORD 
DESCRIPTION 

(B-x\MCW-i-n) 

9-129 

^Measurement  Description  Set 

NUMBER  OE  MEASURANDS 

(B-x\MN\N-i-n) 

MEASUREMENT  NAME 

(B-x\MN-i-n-p) 

MEASUREMENT  TYPE 

(B-x\MT-i-n-p) 

PARITY 

(B-x\MNl-i-n-p) 

PARITY  TRANSEER  ORDER 

(B-x\MN2-i-n-p) 

9-130 

^Measurement  Location 

NUMBER  OE  MEASUREMENT 
LOCATIONS 

(B-x\NML\N-i-n-p) 

MESSAGE  WORD  NUMBER 

(B-x\MWN-i-n-p-e) 

9-130 

BIT  MASK 

(B-x\MBM-i-n-p-e) 

TRANSEER  ORDER 

(B-x\MTO-i-n-p-e) 

ERAGMENT  POSITION 

(B-x\MPP-i-n-p-e) 

*  Comments 

9-131 

COMMENTS 

(B-x\COM) 

*Heading  Only  -  No  Data  Entry 
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Table  9-8.  Bus  Data  Attributes  Group  (B) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

DATA  LINK 
NAME 

B-x\DEN 

Allowed  when:  defining  bus  data 

Identify  the  data  link  name  consistent  with  the 
Multiplex/Modulation  group.  The  PCM  format  of 
the  data  stream  shall  be  defined  in  the  PCM  Eormat 
Attributes  group. 

Required  when:  Allowed 

Einks  from:  R-x\CDEN,  P-d\DEN,  R-x\EV\DEN- 

n 

Range:  32  characters 

TEST  ITEM 

B-x\TA 

Allowed  when:  B\DEN  is  specified 

Test  item  description  in  terms  of  name,  model, 
platform,  or  identification  code  that  contains  the 
data  acquisition  system. 

Range:  16  characters 

BUS  PARITY 

B-x\BP 

Allowed  when:  B\DEN  is  specified 

Specify  whether  the  msb  of  the  1553  words  is  a 
parity  bit.  If  parity  is  used,  it  must  be  odd  parity,  as 
specified  in  Chapter  8,  Paragraph  8.2.2. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

OD 

Odd 

NO 

None 

NUMBER  OE 
BUSES 

B-x\NBS\N 

Allowed  when:  B\ 

DEN  is  specified 

Specify  the  number  of  buses  included  within  this 
data  link.  If  parity  is  used,  the  maximum  is  8 
buses,  and  if  parity  is  not  used,  the  maximum  is  16 
buses,  as  specified  in  Chanter  8,  Paragraph  8.2.3. 

Required  when:  Allowed 

Range:  1-16 

BUS  NUMBER 

B-x\BID-i 

Allowed  when:  B\DEN  is  specified 

Enter  the  bus  number  as  a  binary  string. 

Required  when:  Allowed 

Range:  Binary 

BUS  NAME 

B-x\BNA-i 

Allowed  when:  B\DEN  is  specified 

Specify  the  bus  name. 

Range:  32  characters 

BUS  TYPE 

B-x\BT-i 

Allowed  when:  B\DEN  is  specified 

Specify  the  bus  type. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

1553 

1553  bus 

A429 

ARINC  429  bus 
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Table  9-8. 

Bus  Data  Attributes  Group  (B) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

User-Defined  Words 

USER-DEFINED 

B-x\UMNl-i 

Allowed  when:  defining  chapter  8  bus  data  and 

Specify  the  measurement  name  associated  with  the 

WORD  1 

using  content  ID  label  0010 

content  ID  label  (bits  5-8)  value  of  “0010”. 

MEASUREMENT 

Finks  to:  C-d\DCN 

Range:  32  characters 

PARITY 

B-x\UlP-i 

Allowed  when:  B-x\UMNl-i  is  specified 

Specify  parity. 

Range:  Enumeration 

Enumeration 

Description 

EV 

Even 

OD 

Odd 

NO 

None 

Default:  NO 

PARITY 

B-x\UlPT-i 

Allowed  when:  B\U1P  is  not  “NO” 

Parity  bit  location. 

TRANSFER 

Required  when:  Allowed 

ORDER 

Range:  Enumeration 

Enumeration 

Description 

E 

Eeads  word 

T 

Trails  word 

BIT  MASK 

B-x\UlM-i 

Allowed  when:  B-x\UMNl-i  is  specified 

Binary  string  of  Is  and  Os  to  identify  the  bit 

Range:  Binary  or  ‘ 

‘FW” 

locations  that  are  assigned  to  this  measurement  in 

Default:  FW 

the  word  identified  above.  If  the  full  word  is  used 
for  this  measurement,  enter  “FW”.  Eeft-most  bit 
corresponds  to  the  msb. 

TRANSFER 

B-x\UlT-i 

Allowed  when:  B-x\UMNl-i  is  specified 

Transfer  Order  bit  location. 

ORDER 

Range:  Enumeration 

Enumeration 

Description 

MSB 

msb  first 

ESB 

Isb  first 

DEE 

Default  as  specified  in  WORD 
TRANSFER  ORDER  (P-d\F2) 
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Table  9-8.  Bus  Data  Attributes  Group  (B) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Default:  MSB 

USER-DEFINED 
WORD  2 
MEASUREMENT 

B-x\UMN2-i 

Allowed  when:  defining  chapter  8  bus  data  and 
using  content  ID  label  0011 

Specify  the  measurement  name  associated  with  the 
content  ID  label  (bits  5-8)  value  of  “001 1”. 

Finks  to:  C-d\DCN 

Range:  32  characters 

PARITY 

B-x\U2P-i 

Allowed  when:  B-x\UMN2-i  is  specified 

Specify  parity. 

Range:  Enumeration 

Enumeration 

Description 

EV 

Even 

OD 

Odd 

NO 

None 

Default:  NO 

PARITY 

TRANSFER 

ORDER 

B-x\U2PT-i 

Allowed  when:  B\U2P  is  not  “NO” 

Parity  bit  location. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

E 

Eeads  word 

T 

Trails  word 

BIT  MASK 

B-x\U2M-i 

Allowed  when:  B-x\UMN2-i  is  specified 

Binary  string  of  Is  and  Os  to  identify  the  bit 
locations  that  are  assigned  to  this  measurement  in 
the  word  identified  above.  If  the  full  word  is  used 
for  this  measurement,  enter  “FW”.  Eeft-most  bit 
corresponds  to  the  msb. 

Range:  Binary  or  “FW” 

Default:  FW 

TRANSFER 

ORDER 

B-x\U2T-i 

Allowed  when:  B-x\UMN2-i  is  specified 

Transfer  Order  bit  location. 

Range:  Enumeration 

Enumeration 

Description 

MSB 

msb  first 

FSB 

Isb  first 
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Table  9-8.  Bus  Data  Attributes  Group  (B) 


Parameter 

Code  Name 

Usage  Attributes 

Definition 

DEE 

Default  as  specified  in  WORD 
TRANSFER  ORDER  (P-d\F2) 

Default:  MSB 

USER-DEFINED 

B-x\UMN3-i 

Allowed  when:  defining  chapter  8  bus  data  and 

Specify  the  measurement  name  associated  with  the 

WORD  3 

using  content  ID  label  0100 

content  ID  label  (bits  5-8)  value  of  “0100”  (valid 

MEASUREMENT 

Finks  to:  C-d\DCN 

only  for  1553,  when  response  time  is  not  used). 

Range:  32  characters 

PARITY 

B-x\U3P-i 

Allowed  when:  B-x\UMN3-i  is  specified 

Specify  parity. 

Range:  Enumeration 

Enumeration 

Description 

EV 

Even 

OD 

Odd 

NO 

None 

Default:  NO 

PARITY 

B-x\U3PT-i 

Allowed  when:  B\U3P  is  not  “NO” 

Parity  bit  location. 

TRANSFER 

Required  when:  Allowed 

ORDER 

Range:  Enumeration 

Enumeration 

Description 

E 

Eeads  word 

T 

Trails  word 

BIT  MASK 

B-x\U3M-i 

Allowed  when:  B-x\UMN3-i  is  specified 

Binary  string  of  Is  and  Os  to  identify  the  bit 

Range:  Binary  or  ‘ 

‘FW” 

locations  that  are  assigned  to  this  measurement  in 

Default:  FW 

the  word  identified  above.  If  the  full  word  is  used 
for  this  measurement,  enter  “FW”.  Eeft-most  bit 
corresponds  to  the  msb. 

TRANSFER 

B-x\U3T-i 

Allowed  when:  B-x\UMN3-i  is  specified 

Transfer  Order  bit  location. 

ORDER 

Range:  Enumeration 

Enumeration 

Description 

MSB 

msb  first 

9-124 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  9,  July  2017 


Table  9-8.  Bus  Data  Attributes  Group  (B) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

ESB 

Isb  first 

DEE 

Default  as  specified  in  WORD 
TRANSFER  ORDER  (P-d\F2) 

Default:  MSB 

Recording  Description 

NUMBER  OF 
TRACKS 

B-x\TK\N-i 

Allowed  when:  B\DEN  specified 

Enter  the  number  of  tape  tracks  used  to  record  data. 
Any  entry  greater  than  one  indicates  that  the  data 
has  been  spread  across  multiple  tracks. 

Range:  Non-Negative  Integer 

Default:  0 

TRACK 

SEQUENCE 

B-x\TS-i-k 

Allowed  when:  B\TK\N  >  1 

In  these  entries,  give  the  sequence  order  of  tape 
tracks  that  should  be  used  to  recover  the  data 
stream  in  the  correct  order.  The  order  given  should 
correspond  to  the  actual  skew  of  the  data  on  the 
tape. 

Required  when:  Allowed 

Range:  Positive  Integer 

Message  Content  Definition 

NUMBER  OF 
MESSAGES 

B-x\NMS\N-i 

Allowed  when:  B\TK\N  >  1 

The  number  of  messages  to  be  defined. 

Required  when:  Allowed 

Range:  Positive  Integer 

MESSAGE 

NUMBER 

B-x\MID-i-n 

Allowed  when:  B\TK\N  >  1 

The  message  number  that  contains  the  following 
data. 

Range:  Positive  Integer 

MESSAGE 

NAME 

B-x\MNA-i-n 

Allowed  when:  B\TK\N  >  1 

Specify  the  message  name. 

Range:  32  characters 

COMMAND 
WORD  ENTRY 

B-x\CWE-i-n 

Allowed  when:  dB-x\BT-I  is  1553 

Method  used  to  specify  the  command  word. 

Range:  Enumeration 

Enumeration 

Description 

W 

Enter  the  entire  command 
word  in  the  COMMAND 
WORD  attribute 
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Table  9-8.  Bus  Data  Attributes  Group  (B) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

E 

Enter  command  word  fields 
separately  in  the  REMOTE 
TERMINAE  ADDRESS, 
SUBTERMINAE  ADDRESS, 
TRANSMIT/RECEIVE 

MODE,  and  DATA  WORD 
COUNT/MODE  CODE 
attributes 

Default:  E 

COMMAND 

WORD 

B-x\CMD-i-n 

Allowed  when:  B-x\CWE-i-n  is  “W” 

Specify  the  entire  command  word  for  this  message. 

Required  when:  Allowed 

Range:  Hexadecimal 

REMOTE 

TERMINAE 

NAME 

B-x\TRN-i-n 

Allowed  when:  B-x\CWE-i-n  is  “E” 

Enter  the  name  of  the  remote  terminal  that  is 
sending  or  receiving  this  message.  Eor  RT/RT, 
specify  the  sending  remote  terminal  name. 

Range:  32  characters 

REMOTE 

TERMINAE 

ADDRESS 

B-x\TRA-i-n 

Allowed  when:  B-x\CWE-i-n  is  “E” 

Specify  the  five-bit  remote  terminal  address  for  this 
message. 

Required  when:  Allowed 

Range:  Binary 

SUBTERMINAE 

NAME 

B-x\STN-i-n 

Allowed  when:  B-x\CWE-i-n  is  “E” 

Enter  the  name  of  the  subterminal  that  is  sending  or 
receiving  this  message. 

Range:  32  characters 

SUBTERMINAE 

ADDRESS 

B-x\STA-i-n 

Allowed  when:  B-x\CWE-i-n  is  “E” 

Specify  the  five-bit  subterminal  address  for  this 
message.  Use  “X”  to  indicate  a  “don’t  care”  value. 

Required  when:  Allowed 

Range:  Binary  pattern  of  5 

TRANSMIT/ 
RECEIVE  MODE 

B-x\TRM-i-n 

Allowed  when:  B-x\CWE-i-n  is  “E” 

Indicate  if  this  command  word  is  a  transmit  or 
receive  command.  Eor  RT/RT,  specify  transmit. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

1 

Transmit 

0 

Receive 
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Table  9-8.  Bus  Data  Attributes  Group  (B) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

DATA  WORD 

COUNT/MODE 

CODE 

B-x\DWC-i-n 

Allowed  when:  B-x\CWE-i-n  is  “E” 

Enter  the  number  of  data  words  as  a  binary  string, 
using  “X”  to  indicate  a  “don’t  care”  value.  If  the 
subterminal  address  indicates  a  mode  code,  enter 
the  mode  code  value  as  a  binary  string. 

Required  when:  Allowed 

Range:  Binary  pattern  of  5 

SPECIAE 

PROCESSING 

B-x\SPR-i-n 

Allowed  when:  B\DEN  is  specified 

Provide  any  special  processing  requirements 
pertaining  to  this  message. 

Range:  200  characters 

ARINC  429  Message  Definition 

ARINC  429 

EABEE 

B-x\EBE-i-n 

Allowed  when:  B-x\BT-i  is  “A429” 

Specify  the  eight-bit  ARINC  429  label  for  this 
message. 

Required  when:  Allowed 

Range:  8  Binary  digits 

ARINC  429  SDI 
CODE 

B-x\SDI-i-n 

Allowed  when:  B-x\BT-i  is  “A429” 

Specify  the  two-bit  ARINC  429  SDI  code  for  this 
message. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

AEE 

All  SDI 

0 

SDI  code  0 

1 

SDI  code  1 

2 

SDI  code  2 

3 

SDI  code  3 

RT/RT  Receive  Command  List 

RECEIVE 
COMMAND 
WORD  ENTRY 

B  -x\RCWE-i-n 

Allowed  when:  B\DEN  is  specified 

Method  used  to  specify  the  receive  command  word. 
Default  is  “E”. 

Range:  Enumeration 

Enumeration 

Description 

W 

Enter  the  entire  command 
word  in  the  RECEIVE 
COMMAND  WORD  attribute. 
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Table  9-8.  Bus  Data  Attributes  Group  (B) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

E 

Enter  the  command  word 
fields  separately  in  the 
REMOTE  TERMINAE 
ADDRESS,  SUBTERMINAE 
ADDRESS,  and  DATA 

WORD  COUNT  attributes. 

RECEIVE 

COMMAND 

WORD 

B-x\RCMD-i-n 

Allowed  when:  B-x\RCWE-i-n  is  “W” 

Specify  the  entire  receive  command  word  for  this 
RT/RT  message. 

Required  when:  Allowed 

Range:  Hexadecimal 

REMOTE 

TERMINAE 

NAME 

B-x\RTRN-i-n 

Allowed  when:  B-x\RCWE-i-n  is  “E” 

Enter  the  name  of  the  remote  terminal  that  is 
receiving  this  RT/RT  message. 

Range:  32  characters 

REMOTE 

TERMINAE 

ADDRESS 

B-x\RTRA-i-n 

Allowed  when:  B-x\RCWE-i-n  is  “E” 

Specify  the  five-bit  remote  terminal  address  for  this 
RT/RT  message. 

Required  when:  Allowed 

Range:  Binary 

SUBTERMINAE 

NAME 

B-x\RSTN-i-n 

Allowed  when:  B-x\RCWE-i-n  is  “E” 

Enter  the  name  of  the  sub-terminal  that  is  receiving 
this  RT/RT  message. 

Range:  32  characters 

SUBTERMINAE 

ADDRESS 

B-x\RSTA-i-n 

Allowed  when:  B-x\RCWE-i-n  is  “E” 

Specify  the  five-bit  subterminal  address  for  this 
RT/RT  message.  Use  “X”  to  indicate  a  “don’t 
care”  value. 

Required  when:  Allowed 

Range:  Binary  Pattern  of  5 

DATA  WORD 
COUNT 

B-x\RDWC-i-n 

Allowed  when:  B-x\RCWE-i-n  is  “E” 

Enter  the  number  of  data  words  as  a  binary  string, 
using  “X”  to  indicate  a  “don’t  care”  value.  Exclude 
status  and  time  words.  An  RT/RT  message  cannot 
contain  a  mode  code. 

Required  when:  Allowed 

Range:  Binary  Pattern  of  5 

Mode  Code 

MODE  CODE 
DESCRIPTION 

B-x\MCD-i-n 

Allowed  when:  B-x\DWC-i-n  is  00000  or  11111 

Describe  the  function  or  action  associated  with  this 
mode  code. 

Range:  200  characters 

MODE  CODE 
DATA  WORD 
DESCRIPTION 

B-x\MCW-i-n 

Allowed  when:  B-x\DWC-i-n  is  00000  or  11111 

If  the  mode  code  has  an  associated  data  word 
following  the  mode  code  command,  provide  a 
complete  description  of  the  data  word. 

Range:  200  characters 
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Table  9-8. 

Bus  Data  Attributes  Group  (B) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Measurement  Description  Set 

NUMBER  OF 

B-x\MN\N-i-n 

Allowed  when:  B\DEN  is  specified 

Specify  the  number  of  measurands. 

MEASURANDS 

Required  when:  Allowed 

Range:  Positive  Integer 

MEASUREMENT 

B-x\MN-i-n-p 

Allowed  when:  B\DEN  is  specified 

Measurand  name. 

NAME 

Required  when:  Allowed 

Finks  to:  C-d\DCN 

Finks  from:  R-x\BME\SMN-n-m 

Range:  32  characters 

MEASUREMENT 

B-x\MT-i-n-p 

Allowed  when:  B\DEN  is  specified 

Content  identification. 

TYPE 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

D 

Data  word 

C 

Command  word 

S 

Status  word 

T 

Time  word 

PARITY 

B-x\MNl-i-n-p 

Allowed  when:  B\ 

DEN  is  specified 

Specify  parity. 

Status:  Optional 

Range:  Enumeration 

Enumeration 

Description 

EV 

Even 

OD 

Odd 

NO 

None 

Default:  NO 

PARITY 

B-x\MN2-i-n-p 

Allowed  when:  B\MN1  is  not  “NO” 

Parity  bit  location. 

TRANSFER 

Required  when:  Allowed 

ORDER 

Range:  Enumeration 

Enumeration 

Description 
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Table  9-8. 

Bus  Data  Attributes  Group  (B) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

E 

Eeads  word 

T 

Trails  word 

Measurement  Location 

NUMBER  OF 

B-x\NME\N-i-n-p 

Allowed  when:  B\DEN  is  specified 

If  this  measurement  is  contained  in  one  word,  enter 

MEASUREMENT 

Required  when:  Allowed 

“1”.  If  this  measurement  is  fragmented,  enter  the 

EOCATIONS 

Range:  1-8 

number  of  fragments. 

MESSAGE 

B-x\MWN-i-n-p- 

Allowed  when:  B\DEN  is  specified 

Enter  the  data  word  number  within  a  message  that 

WORD  NUMBER 

e 

Required  when:  Allowed 

contains  the  measurement  or  the  fragmented 

Range:  Positive  Integer 

measurand. 

BIT  MASK 

B-x\MBM-i-n-p-e 

Allowed  when:  B\DEN  is  specified 

Binary  string  of  Is  and  Os  to  identify  the  bit 

Range:  Binary  or  ‘ 

‘FW” 

locations  that  are  assigned  to  this  measurement  in 

Default:  FW 

the  word  identified  above.  If  the  full  word  is  used 
for  this  measurement,  enter  “FW”.  Eeft-most  bit 
corresponds  to  the  msb. 

TRANSFER 

B-x\MTO-i-n-p-e 

Allowed  when:  B\DEN  is  specified 

Bit  transfer  order  for  the  measurement. 

ORDER 

Range:  Enumeration 

Enumeration 

Description 

MSB 

msb  first. 

FSB 

Isb  bit  first. 

DEE 

Default  as  specified  in  WORD 
TRANSFER  ORDER  (P- 
d\F2). 

Default:  MSB 

FRAGMENT 

B-x\MFP-i-n-p-e 

Allowed  when:  B\DEN  is  specified 

A  number  from  1  to  N  specifying  the  position  of 

POSITION 

Range:  1-8 

this  fragment  within  the  reconstructed  binary  data 

Required  when:  B\NME\N  is  greater  than  1 

word.  1  corresponds  to  the  most  significant 
fragment.  Each  fragment  position  from  1  to  N 
must  be  specified  only  once. 

NOTE:  Repeat  the  above  to  describe  each  fragment  of  a  fragmented  word.  The  transfer  order  indicates  whether  to  transpose  the  order  of  the  bit 

sequence  or  not  (Isb  indicates  to  transpose  the  bit  sequence). 
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Table  9-8.  Bus  Data  Attributes  Group  (B) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Comments 

COMMENTS 

B-x\COM 

Allowed  when:  B\DLN  is  specified 

Provide  the  additional  information  requested  or 

Range:  3200  characters 

other  information  desired. 
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d.  Message  Data  Attributes  (S).  The  Message  Data  Attributes  are  presented  graphically  in 
Figure  9-9  and  specified  in  Table  9-9.  The  information  contained  within  this  group  is 
used  to  describe  the  characteristics  and  measurement  locations  within  data  streams  as 
described  by  the  UART,  Message,  Ethernet,  IEEE-1394,  and  Eibre  Channel  Chapter  10 
channel  data  types. 


Figure  9-9. 

Message  Data  Attributes  Group  (S) 

Code  Name 

DATA  LINK  NAME  -  9-134 

(S-d\DEN) 

TEST  ITEM 

(S-d\TA) 

NUM 

[BER  OE  STREAMS 

(S-d\NS\N) 

STREAM  NAME 

(S-d\SNA-i) 

MESSAGE  DATA  TYPE 

(S-d\MDT-i) 

MESSAGE  DATA  EAYOUT 

(S-d\MDE-i) 

MESSAGE  EEEMENT  SIZE 

(S-d\MES-i) 

MESSAGE  ID  EOCATION 

(S-d\MIDE-i) 

MESSAGE  EENGTH 

(S-d\MEEN-i) 

MESSAGE  DEEIMITER 

(S-d\MDEE-i) 

MESSAGE  DEEIMITER  EENGTH 

(S-d\MDEEN-i) 

EIEED  DEEIMITER 

(S-d\PDEE-i) 

DATA  ORIENTATION 

(S-d\DO-i) 
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^Message  Content  Definition 

NUMBER  OE  MESSAGES 

(S-d\NMS\N-i) 

MESSAGE  ID 

(S-d\MID-i-n) 

MESSAGE  DESCRIPTION 

(S-d\MNA-i-n) 

NUMBER  OE  EIEEDS 

(S-d\NPEDS\N-i-n) 

EIEED  NUMBER 

(S-d\PNUM-i-n-m) 

EIEED  START 

(S-d\PPOS-i-n-m) 

EIEED  EENGTH 

(S-d\PEEN-i-n-m) 
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*Measurement  Description  Set 

NUMBER  OE  MEASURANDS 

(S-d\MN\N-i-n) 

MEASUREMENT  NAME 

(S-d\MN-i-n-p) 

PARITY 

(S-d\MNl-i-n-p) 

PARITY  TRANSEER  ORDER 

(S-d\MN2-i-n-p) 

DATA  TYPE 

(S-d\MBPM-i-n-p) 

EEOATING  POINT  EORMAT 

(S-d\MPPP-i-n-p) 

DATA  ORIENTATION 

(S-d\MDO-i-n-p) 

9-138 

*M 

leasurement  Location 

NUMBER  OE  MEASUREMENT 
EOCATIONS 

(S-d\NME\N-i-n-p) 

MESSAGE  EIEED  NUMBER 

(S-d\MPN-i-n-p-e) 

BIT  MASK 

(S-d\MBM-i-n-p-e) 

TRANSEER  ORDER 

(S-d\MTO-i-n-p-e) 

ERAGMENT  POSITION 

(S-d\MPP-i-n-p-e) 

9-139 

*  Comments 

COMMENTS 

(S-d\COM) 
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*Heading  Only  -  No  Data  Entry 
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Table  9-9.  Message  Data  Attributes  Group  (S) 


Parameter 


Code  Name 


Usage  Attributes 


Definition 


DATA  LINK 
^ME 


S-d\DLN 


Allowed  when:  R\CDT  is  either  “UARTIN”  or 
“MSGIN”  or  “ETHIN”  or  “EBCHIN” 


Identify  the  data  link  name  consistent  with  the 
Recorder-Reproducer  group. 


Required  when:  Allowed 


Einks  from:  R-x\CDEN,  R-x\EV\DEN-n 


Range:  32  characters 


TEST  ITEM 


S-d\TA 


Allowed  when:  S\DEN  is  specified 


Range:  16  characters 


Test  item  description  in  terms  of  name,  model, 
platform,  or  identification  code  that  contains  the  data 
acquisition  system. 


NUMBER  OE 
STREAMS 


S-d\NS\N 


Allowed  when:  S\DEN  is  specified 


Required  when:  Allowed 


Specify  the  number  of  message  data  streams  included 
within  this  data  link. 


Range:  2  characters 


STREAM  NAME 


S-d\SNA-i 


Allowed  when:  S\DEN  is  specified 


Required  when:  Allowed 


Specify  the  message  data  stream  name  (subchannel 
name  or  same  as  data  link  name  if  no  subchannel). 


Range:  32  characters 


MESSAGE  DATA 
TYPE 


S-d\MDT-i 


Allowed  when:  S\DEN  is  specified 


Data  type  -  “ASCII”  or  “BINARY”. 


Range:  Enumeration 


Enumeration 


ASCII 


BINARY 


Description 


Default:  ASCII 


MESSAGE  DATA 
EAYOUT 


S-d\MDE-i 


Allowed  when:  S\DEN  is  specified 


Specify  message  data  layout. 


Required  when:  Allowed 


Range:  Enumeration 


Enumeration 


DEEIMITED 


EIXED 


Description 


Data  layout  [ASCII  data  type 
only] 


ASCII  or  binary  data  types. 
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Table  9-9.  Message  Data  Attributes  Group  (S) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

MESSAGE 
EEEMENT  SIZE 

S-d\MES-i 

Allowed  when:  S\DEN  is  specified 

Element  size  in  number  of  bits. 

Required  when:  Allowed 

Range:  2  characters 

Default:  8 

MESSAGE  ID 
EOCATION 

S-d\MIDE-i 

Allowed  when:  S\DEN  is  specified 

Message  ID  field  number. 

Required  when:  Allowed 

Range:  4  characters 

MESSAGE 

EENGTH 

S-d\MEEN-i 

Allowed  when:  S-d\MDE-I  is  “EIXED” 

Message  length  in  number  of  message  elements  (fixed 
data  layout  only). 

Required  when:  Allowed 

Range:  8  characters 

MESSAGE 

DEEIMITER 

S-d\MDEE-i 

Allowed  when:  S-d\MDE-I  is  “DEEIMITED” 

Message  delimiter  -  “CREE”  or  “CR”  or  “EE”  or  hex 
value  (delimited  layout  only). 

Required  when:  Allowed 

Range:  Hex  or  Enums 

MESSAGE 

DEEIMITER 

EENGTH 

S-d\MDEEN-i 

Allowed  when:  S-d\MDE-I  is  “DEEIMITED” 

Message  delimiter  length  in  number  of  message 
elements  (delimited  layout  only). 

Required  when:  Allowed 

Range:  2  characters 

EIEED 

DEEIMITER 

S-d\EDEE-i 

Allowed  when:  S-d\MDE-I  is  “DEEIMITED” 

Eield  delimiter  -  or  “1”,  or  “blank”  or  “tab”,  or  hex 

value  (delimited  layout  only). 

Required  when:  Allowed 

Range:  Hex  or  Enums 

NOTE;  A  field  is  a  set  of  elements  determined  by  the  number  of  elements  or  elements  between  field  delimiters.  A  message  consists  of  one  or 
more  fields,  which  can  be  fixed  or  variable  length. 


DATA 

S-d\DO-i 

Allowed  when:  S-d\MDT-I  =  “BINARY”. 

Data  orientation.  Binary  data  type  only. 

ORIENTATION 

Range:  Enumeration 

Enumeration 

Description 

E 

Eittle  endian 

B 

Big  endian 

Default:  Big  Endian 
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Table  9-9.  Message  Data  Attributes  Group  (S) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Message  Content  Definition 

NUMBER  OF 
MESSAGES 

S-d\NMS\N-i 

Allowed  when:  S\DEN  is  specified 

The  number  of  messages  to  be  defined. 

Required  when:  Allowed 

Range:  8  characters 

MESSAGE  ID 

S-d\MID-i-n 

Allowed  when:  S-d\MIDE-I  is  not  “0” 

Message  ID  value.  ASCII  value  in  quotes  or  hex 
value. 

Required  when:  Allowed 

Range:  ASCII  or  Hex 

MESSAGE 

DESCRIPTION 

S-d\MNA-i-n 

Allowed  when:  S-d\MIDE-I  is  not  “0” 

Message  description. 

Range:  64  characters 

NUMBER  OF 
FIEEDS 

S-d\NFEDS\N-i-n 

Allowed  when:  S-d\MIDE-I  is  not  “0” 

Number  of  fields  in  the  message. 

Required  when:  Allowed 

Range:  4  characters 

FIFED  NUMBER 

S-d\FNUM-i-n-m 

Allowed  when:  S-d\MIDE-I  is  not  “0” 

Specify  the  field  number. 

Required  when:  Allowed 

Range:  4  characters 

FIFED  START 

S-d\FPOS-i-n-m 

Allowed  when:  S-d\MDE-I  is  “FIXED” 

Enter  the  element  position  of  the  field  (only  for  fixed 
column  message  data  layout). 

Required  when:  Allowed 

Range:  5  characters 

FIFED  EENGTH 

S-d\FEEN-i-n-m 

Allowed  when:  S-d\MDE-I  is  “FIXED” 

Enter  the  field  length  (only  for  fixed  message  data 
layout).  If  message  data  type  is  ASCII,  ASCII  string 
in  field  is  converted  to  specified  data  type,  i.e.,  float. 

If  message  data  type  is  binary,  field  is  cast  as  specified 
data  type,  i.e.,  unsigned,  signed,  float,  ASCII,  etc. 

Required  when:  Allowed 

Range:  5  characters 

Measurement  Description  Set 

NUMBER  OF 
MEASURANDS 

S-d\MN\N-i-n 

Allowed  when:  S\DEN  is  specified 

Specify  the  number  of  measurands. 

Range:  4  characters 

MEASUREMENT 

NAME 

S-d\MN-i-n-p 

Allowed  when:  S\MN\N  >  0 

Measurand  name. 

Finks  to:  C-d\DCN 

Range:  32  characters 
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Table  9-9. 

Message  Data  Attributes  Group  (S) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

PARITY 

S-d\MNl-i-n-p 

Allowed  when:  S\MN\N  >  0 

Normal  word  parity. 

Range:  Enumeration 

Enumeration 

Description 

EV 

Even 

OD 

Odd 

NO 

None 

Default:  NO 

PARITY 

TRANSEER 

ORDER 

S-d\MN2-i-n-p 

Allowed  when:  S\MN\N  >  0 

Parity  bit  location. 

Range:  Enumeration 

Enumeration 

Description 

E 

Eeads  word 

T 

Trails  word 

DATA  TYPE 

S-d\MBEM-i-n-p 

Allowed  when:  S\MN\N  >  0 

Data  type.  If  message  data  type  is  binary  then  only 

Range:  Enumeration 

ASCII,  signed,  unsigned,  and  float  are  valid. 

Enumeration 

Description 

ASCII 

ASCII  characters 

EEOAT 

Binary  floating  point  data 

SIGNED 

Binary  signed  integer  data 

UNSIGNED 

Binary  unsigned  integer  data 

HEX 

ASCII  characters  0-9,  A-E 

OCTAE 

ASCII  characters  0-7 

BINARY 

ASCII  characters  0  and  I 

NOTE;  For  binary  messages,  the  data  type  describes  the  format  of  the  raw  input  data  as  it  appears  in  the  stream.  If  FLOAT  is  specified  in  a 
binary  message,  the  floating  point  format  attribute  describes  the  specific  floating  point  data  type.  For  ASCII  messages,  FLOAT,  SIGNED,  and 
UNSIGNED  define  how  to  interpret  the  ASCII  data  for  conversion  to  an  output  data  type  for  numeric  processing. 


EEOATING 

S-d\MPPP-i-n-p 

Allowed  when:  S\MN\N  >  0 

If  data  type  is  “float”,  specify  which  floating  point 

POINT  EORMAT 

Range:  Enumeration 

format  will  be  used.  Only  for  binary  message  data 

Enumeration 

Description 

tvpe.  See  Appendix  9-D  for  more  information. 

IEEE_32 

IEEE  754  single  precision 
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Table  9-9.  Message  Data  Attributes  Group  (S) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

IEEE_64 

IEEE  754  double  precision 

1750A_32 

MIE-STD  1750A  single 
precision 

1750A_48 

MIE-STD  1750A  double 
precision 

DEC_32 

DEC  single  precision 

DEC_64 

DEC  double  precision 

DEC_64G 

DEC  “G”  double  precision 

IBM_32 

IBM  single  precision 

IBM_64 

IBM  double  precision 

TI_32 

TI  single  precision 

TI 40 

TI  extended  precision 

DATA 

ORIENTATION 

S-d\MDO-i-n-p 

Allowed  when:  S\MN\N  >  0 

Data  orientation.  Binary  data  type  only. 

Range:  Enumeration 

Enumeration 

Description 

E 

Eittle  endian 

B 

Big  endian 

Default:  Big  Endian 

Measurement  Location 

NUMBER  OE 

MEASUREMENT 

EOCATIONS 

S-d\NME\N-i-n-p 

Allowed  when:  S\MN\N  >  0 

Range:  2  characters 

If  this  measurement  is  contained  in  one  field,  enter 
“1”.  If  this  measurement  is  fragmented,  enter  the 
number  of  fragments. 

MESSAGE 

EIEED  NUMBER 

S-d\MEN-i-n-p-e 

Allowed  when:  S\NME\N  >  0 

Range:  4  characters 

Enter  the  field  number  within  a  message  that  contains 
the  measurement  or  the  fragmented  measurand. 

BIT  MASK 

S-d\MBM-i-n-p-e 

Allowed  when:  S\NME\N  >  0 

Range:  Binary  or  EW 

Binary  string  of  Is  and  Os  to  identify  the  bit  locations 
that  are  assigned  to  this  measurement  in  the  field 
identified  above.  If  the  entire  field  is  used  for  this 
measurement,  enter  “EW”.  Eeft-most  bit  corresponds 
to  the  msb. 
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Table  9-9.  Message  Data  Attributes  Group  (S) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

TRANSFER 

ORDER 

S-d\MTO-i-n-p-e 

Allowed  when:  S\NME\N  >  0 

Range:  Enumeration 

Specify  transfer  order  bit  as  most  significant  or  least 
significant. 

Enumeration 

Description 

MSB 

msb 

ESB 

Isb 

ERAGMENT 

POSITION 

S-d\MEP-i-n-p-e 

Allowed  when:  S\NME\N  >  0 

Range:  1-8 

A  number  from  1  to  N  specifying  the  position  of  this 
fragment  within  the  reconstructed  binary  field.  1 
corresponds  to  the  most  significant  fragment.  Each 
fragment  position  from  1  to  N  must  be  specified  only 
once. 

NOTE:  Repeat  the  above  to  describe  eac 
sequence  or  not  (Isb  indicates  to  transpose 

1  fragment  of  a  fragmented  field.  The  transfer  order  indicates  whether  to  transpose  the  order  of  the  bit 
the  bit  sequence). 

Comments 

COMMENTS 

S-d\COM 

Allowed  when:  S\DEN  is  specified 

Range:  3200  characters 

Provide  the  additional  information  requested  or  any 
other  information  desired. 
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9.5.7  Data  Conversion  Attributes  (C) 

The  Data  Conversion  Attributes  group  ineludes  a  definition  of  the  method  by  whieh  the 
raw  telemetry  data  is  to  be  eonverted  to  meaningful  information.  The  sensor  ealibration  is 
contained  in  the  group  for  each  type  of  sensor  that  uses  a  standard  calibration  curve  or  for  each 
sensor  or  parameter  that  has  a  unique  calibration  requirement.  The  calibration  information  can 
be  entered  in  several  different  formats.  Provision  is  made  to  permit  a  test  organization  to  convert 
data  set  entries  to  coefficients  of  an  appropriate  curve  fit  and  record  the  derived  coefficients. 
Figure  9-10  shows  the  structure  of  the  data  conversion  attributes.  Table  9-10  contains  the 
detailed  information  required. 


NOTE 


For  reference  purposes,  the  following  telemetry  unit  definitions  apply: 

•  PCM  -  natural  binary  range  as  indicated  by  binary  format  entry 

•  FM  (Analog)  -  lower  band  edge  (-100)  to  upper  band  edge  (-1-100). 


Figure  9-10.  Data  Conversion  Attributes  Group  (C) 

Code  Name 

MEASUREMENT  NAME  -  9-143 

(C-d\DCN) 

9-143 

*  Transducer  Information 

TYPE 

(C-d\TRDI) 

MODEL  NUMBER 

(C-d\TRD2) 

SERIAL  NUMBER 

(C-d\TRD3) 

SECURITY  CLASSIEICATION 

(C-d\TRD4) 

ORIGINATION  DATE 

(C-d\TRD5) 

REVISION  NUMBER 

(C-d\TRD6) 

ORIENTATION 

(C-d\TRD7) 

9-144 

*Point  of  Contact 

NAME 

(C-d\POCI) 

AGENCY 

(C-d\POC2) 

ADDRESS 

(C-d\POC3) 

TELEPHONE 

(C-d\POC4) 

9-144 

*Measurand 

DESCRIPTION 

(C-d\MNI) 

MEASUREMENT  ALIAS 

(C-d\MNA) 

EXCITATION  VOLTAGE 

(C-d\MN2) 

ENGINEERING  UNITS 

(C-d\MN3) 

LINK  TYPE 

(C-d\MN4) 

9-144 

*  Telemetry  Value  Definition 

BINARY  EORMAT 

(C-d\BEM) 

*Floating  Point 

ELOATING  POINT  EORMAT 

(C-d\EPE) 

*Bit  Weight 

NUMBER  OE  BITS 

(C-d\BWT\N) 

BIT  NUMBER 

(C-d\BWTB-n) 

BIT  WEIGHT  VALUE 

(C-d\BWTV-n) 

9-146 

*In-Flight  Calibration 
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NUMBER  OF  POINTS 

(C-d\MC\N) 

STIMULUS 

(C-d\MCl-n) 

TELEMETRY  VALUE 

(C-d\MC2-n) 

DATA  VALUE 

(C-d\MC3-n) 

9-147 

*Am 

bient  Value 

NUMBER  OF  AMBIENT  CONDITIONS 

(C-d\MA\N) 

STIMULUS 

(C-d\MAl-n) 

TELEMETRY  VALUE 

(C-d\MA2-n) 

DATA  VALUE 

(C-d\MA3-n) 

9-147 

*  Other  Information 

HIGH  MEASUREMENT  VALUE 

(C-d\MOTl) 

LOW  MEASUREMENT  VALUE 

(C-d\MOT2) 

HIGH  ALERT  LIMIT  VALUE 

(C-d\MOT3) 

LOW  ALERT  LIMIT  VALUE 

(C-d\MOT4) 

HIGH  WARNING  LIMIT  VALUE 

(C-d\MOT5) 

LOW  WARNING  LIMIT  VALUE 

(C-d\MOT6) 

INITIAL  VALUE 

(C-d\MOT7) 

SAMPLE  RATE 

(C-d\SR) 

9-148 

*Data  Conversion 

DATE  AND  TIME  RELEASED 

(C-d\CRT) 

CONVERSION  TYPE 

(C-d\DCT) 

9-149 

^Engineering  Units  Conversion 

9-149 

*Pair  Sets 

NUMBER  OF  SETS 

(C-d\PS\N) 

APPLICATION 

(C-d\PSl) 

ORDER  OF  FIT 

(C-d\PS2) 

TELEMETRY  VALUE 

(C-d\PS3-n) 

ENGINEERING  UNITS  VALUE 

(C-d\PS4-n) 

9-149 

OR 

*  Coefficients 

ORDER  OF  CURVE  FIT 

(C-d\CO\N) 

9-150 

DERIVED  FROM  PAIR  SET 

(C-d\C01) 

COEFFICIENT  (0) 

(C-d\CO) 

N-TH  COEFFICIENT 

(C-d\CO-n) 

OR 

^Coefficients  (Negative  Powers  of  X) 

ORDER 

(C-d\NPC\N) 

DERIVED  FROM  PAIR  SET 

(C-d\NPCl) 

COEFFICIENT  (0) 

(C-d\NPC) 

N-TH  COEFFICIENT 

(C-d\NPC-n) 

9-151 

OR 

*Ot 

ler 

DEFINITION  OF  OTHER  DATA 
CONVERSION 

(C-d\OTH) 

9-151 

OR 

^Derived  Parameter 

ALGORITHM  TYPE 

(C-d\DPAT) 

ALGORITHM 

(C-d\DPA) 

TRIGGER  MEASURAND 

(C-d\DPTM) 
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NUMBER  OE  OCCURRENCES 

(C-d\DPNO) 

NUMBER  OE  INPUT  MEASURANDS 

(C-d\DP\N) 

MEASURAND  #N 

(C-d\DP-n) 

NUMBER  OE  INPUT  CONSTANTS 

(C-d\DPC\N) 

CONSTANT  #N 

(C-d\DPC-n) 

9-152 

OR 

*Discrete 

NUMBER  OE  EVENTS 

(C-d\DIC\N) 

NUMBER  OE  INDICATORS 

(C-d\DICEN) 

CONVERSION  DATA 

(C-d\DICC-n) 

PARAMETER  EVENT  DEEINITION 

(C-d\DICP-n) 

9-152 

OR 

*  PCM  Time 

PCM  TIME  WORD  EORMAT 

(C-d\PTM) 

9-153 

OR 

*  1553  Time 

1553  TIME  WORD  EORMAT 

(C-d\BTM) 

9-153 

OR 

*Dis 

»ital  Voice 

ENCODING  METHOD 

(C-dWOEE) 

DESCRIPTION 

(C-dWOED) 

9-153 

OR 

*Dis 

»ital  Video 

ENCODING  METHOD 

(C-d\VID\E) 

DESCRIPTION 

(C-d\VID\D) 

*  Comments 

9-154 

COMMENTS 

(C-d\COM) 

^Heading  Only 

-  No  Data  Entry 
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Table  9-10.  Data  Conversion  Attributes  Group  (C) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

MEASUREMENT 

NAME 

C-d\DCN 

Allowed  when:  Always 

Give  the  measurement  name. 

Einks  from:  R-x\AMN-n-m  ,  R-x\AMN-n-m 
M-x\SEMN-n  ,  M-x\BB\MN  ,  D-x\MN-y-n  , 
B-x\UMNl-i ,  B-x\UMN2-i ,  B-x\UMN3-i ,  B- 
x\MN-i-n-p  ,  S-d\MN-i-n-p,  R-x\DMN-n-m 

Range:  32  characters 

Transducer  Information 

TYPE 

C-d\TRDl 

Allowed  when:  C-d\DCN  is  specified 

Type  of  sensor,  if  appropriate. 

Range:  32  characters 

MODEE  NUMBER 

C-d\TRD2 

Allowed  when:  C-d\DCN  is  specified 

If  appropriate. 

Range:  32  characters 

SERIAE  NUMBER 

C-d\TRD3 

Allowed  when:  C-d\DCN  is  specified 

If  applicable. 

Range:  32  characters 

SECURITY 

CEASSIEICATION 

C-d\TRD4 

Allowed  when:  C-d\DCN  is  specified 

Enter  the  security  classification  of  this  measurand. 

Append  the  following:  If  received  telemetry  signal 
(Counts)  is  classified,  add  “R”.  If  expressed  in 
engineering  units,  the  measurand  value  is  classified,  add 
“E”.  If  both  are  classified,  add  “B”. 

Range:  Enumeration 

Enumeration 

Description 

U 

Unclassified 

C 

Confidential 

s 

Secret 

T 

Top  secret 

0 

Other 

ORIGINATION 

DATE 

C-d\TRD5 

Allowed  when:  C-d\DCN  is  specified 

Date  of  origination  of  this  data  file.  “DD”  (Day).  “MM” 
(Month).  “YYYY”  (Year). 

Range:  MM-DD-YYYY 

REVISION 

NUMBER 

C-d\TRD6 

Allowed  when:  C-d\DCN  is  specified 

Specify  the  revision  number  of  the  data  provided. 

Range:  4  characters 

ORIENTATION 

C-d\TRD7 

Allowed  when:  C-d\DCN  is  specified 

Describe  the  physical  orientation  of  the  sensor. 

Range:  32  characters 
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Table  9-10.  Data  Conversion  Attributes  Group  (C) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Point  of  Contact 

NAME 

C-d\POCl 

Allowed  when:  C-d\DCN  is  specified 

Point  of  contact  with  the  organization  that  provided  the 
calibration  data. 

Range:  24  characters 

AGENCY 

C-d\POC2 

Allowed  when:  C-d\DCN  is  specified 

Point  of  contact  with  the  organization  that  provided  the 
calibration  data. 

Range:  48  characters 

ADDRESS 

C-d\POC3 

Allowed  when:  C-d\DCN  is  specified 

Point  of  contact  with  the  organization  that  provided  the 
calibration  data. 

Range:  48  characters 

TEEEPHONE 

C-d\POC4 

Allowed  when:  C-d\DCN  is  specified 

Point  of  contact  with  the  organization  that  provided  the 
calibration  data. 

Range:  20  characters 

Measurand 

DESCRIPTION 

C-d\MNl 

Allowed  when:  C-d\DCN  is  specified 

Describe  the  parameter  being  measured. 

Range:  64  characters 

MEASUREMENT 

AEIAS 

C-d\MNA 

Allowed  when:  C-d\DCN  is  specified 

Alternate  measurand  name. 

Range:  32  characters 

EXCITATION 

VOETAGE 

C-d\MN2 

Allowed  when:  C-d\DCN  is  specified 

Sensor  reference  voltage,  in  volts. 

Range:  10  characters 

ENGINEERING 

UNITS 

C-d\MN3 

Allowed  when:  C-d\DCN  is  specified 

Define  the  engineering  units  applicable  to  the  output 
data. 

Range:  16  characters 

EINK  TYPE 

C-d\MN4 

Allowed  when:  C-d\DCN  is  specified 

Define  the  source  data  link  type. 

Range:  Enumeration 

Enumeration 

Description 

ANA 

EM  (analog) 

PCM 

OTH 

Other 

Default:  PCM 

Telemetry  Value  Definition 

BINARY  EORMAT 

C-d\BEM 

Allowed  when:  C-d\DCN  is  specified 

Eormat  of  the  binary  information. 

Required  when:  Allowed 

Range:  Enumeration 
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Table  9-10.  Data  Conversion  Attributes  Group  (C) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Enumeration 

Description 

INT 

Integer 

UNS 

Unsigned  Binary 

SIG 

Sign  And  Magnitude 

Binary  [-i-=0] 

SIM 

Sign  And  Magnitude 

Binary  [-i-=l] 

ONE 

One’s  Complement 

TWO 

Two’s  Complement 

OEE 

Offset  Binary 

EPT 

Eloating  Point 

BCD 

Binary  Coded  Decimal 

BWT 

Bit  Weight 

OTH 

Other,  define  in  comments 

Floating  Point 

FLOATING  POINT 

C-d\FPF 

Allowed  when:  C\BEM  is  “EPT” 

If  binary  format  is  “EPT”,  specify  which  floating  point 

FORMAT 

Required  when:  Allowed 

format  will  be  used.  Other  formats  are  not  excluded. 

Range:  Enumeration 

See  Appendix  9-D  for  more  information. 

Enumeration 

Description 

IEEE 32 

IEEE  754  single  precision 

IEEE 64 

IEEE  754  double  precision 

1750A_32 

MIE-STD-1750A  single 
precision 

1750A_48 

MIE-STD-1750A  double 
precision 

DEC 32 

DEC  single  precision 

DEC 64 

DEC  double  precision 

DEC 64G 

DEC  “G”  double  precision 

IBM_32 

IBM  single  precision 
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Table  9-10.  Data  Conversion  Attributes  Group  (C) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

IBM 64 

IBM  double  precision 

TI 32 

TI  single  precision 

TI 40 

TI  extended  precision 

Bit  Weight 

NUMBER  OF  BITS 

C-d\BWT\N 

Allowed  when:  C\BFM  is  “BWT” 

Specify  the  number  of  bits  that  will  have  a  weighted 
value  assigned. 

Required  when:  Allowed 

Range  1-64 

BIT  NUMBER 

C-d\BWTB-n 

Allowed  when:  C\BFM  is  “BWT” 

Bit  number,  as  defined  in  Chapter  4,  Subparagraph 

4.3. l.c  (msb  is  bit  1). 

Required  when:  Allowed 

Range  1-64 

BIT  WEIGHT 
VAEUE 

C-d\BWTV-n 

Allowed  when:  C\BFM  is  “BWT” 

Numerical  value  indicated  by  each  bit.  To  specify  the 
sign  bit,  enter  “S”. 

Required  when:  Allowed 

Range:  Floating  Point  or  “S” 

In-Flight  Calibration 

NUMBER  OF 
POINTS 

C-d\MC\N 

Allowed  when:  C-d\DCN  is  specified  and 
defining  “Inflight  Calibration” 

Is  in-flight  calibration  required?  “N”  for  no  or  the 
number  of  calibration  points. 

Range:  0-999  or  “N” 

Default:  N 

STIMUEUS 

C-d\MCl-n 

Allowed  when:  C-d\MC\N  is  not  N 

Provide  the  stimulus  for  this  calibration  point. 

Range:  32  characters 

TEEEMETRY 

VAEUE 

C-d\MC2-n 

Allowed  when:  C-d\MC\N  is  not  N 

Telemetry  units  value. 

Required  when:  Allowed 

Range:  Integer 

DATA  VAEUE 

C-d\MC3-n 

Allowed  when:  C-d\MC\N  is  not  N 

Engineering  units  value. 

Required  when:  Allowed 

Range:  Floating  Point 

NOTE:  The  above  set  of  three  entries  must  be  repeated  for  each  in-flight  calibration  point. 
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Table  9-10.  Data  Conversion  Attributes  Group  (C) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Ambient  Value 

NUMBER  OF 

AMBIENT 

CONDITIONS 

C-d\MA\N 

Allowed  when:  C-d\DCN  is  specified  and 
defining  “Ambient  Values” 

Number  of  static  or  simulated  conditions. 

Range:  0-999 

Default:  0 

STIMUEUS 

C-d\MAl-n 

Allowed  when:  C-d\MA\N  is  not  0 

Description  of  the  static  environment  in  which  a  non-test 
stimulus  or  simulator  is  the  data  source. 

Range:  32  characters 

TEEEMETRY 

VAEUE 

C-d\MA2-n 

Allowed  when:  C-d\MA\N  is  not  0 

Telemetry  units  value  for  the  static  stimulus. 

Required  when:  Allowed 

Range:  Integer 

DATA  VAEUE 

C-d\MA3-n 

Allowed  when:  C-d\MA\N  is  not  0 

Engineering  units  value  for  the  static  or  simulated 
condition. 

Required  when:  Allowed 

Range:  Floating  Point 

Other  Information 

HIGH 

MEASUREMENT 

VAEUE 

C-d\MOTl 

Allowed  when:  C-d\DCN  is  specified 

Highest  engineering  unit  value  defined  in  the  calibration 
data. 

Range:  Floating  Point 

EOW 

MEASUREMENT 

VAEUE 

C-d\MOT2 

Allowed  when:  C-d\DCN  is  specified 

Eowest  engineering  unit  value  defined  in  the  calibration 
data. 

Range:  Floating  Point 

HIGH  AEERT 

EIMIT  VAEUE 

C-d\MOT3 

Allowed  when:  C-d\DCN  is  specified 

Highest  engineering  unit  value  expected  or  safe 
operating  value  of  the  parameter  (“red”). 

Range:  Floating  Point 

EOW  AEERT 

EIMIT  VAEUE 

C-d\MOT4 

Allowed  when:  C-d\DCN  is  specified 

Eowest  engineering  unit  value  expected  or  safe  operating 
value  of  the  parameter  (“red”). 

Range:  Floating  Point 

HIGH  WARNING 
EIMIT  VAEUE 

C-d\MOT5 

Allowed  when:  C-d\DCN  is  specified 

Highest  engineering  unit  value  expected  or  safe 
operating  value  of  the  parameter  (“yellow”). 

Range:  Floating  Point 

EOW  WARNING 
EIMIT  VAEUE 

C-d\MOT6 

Allowed  when:  C-d\DCN  is  specified 

Eowest  engineering  unit  value  expected  or  safe  operating 
value  of  the  parameter  (“yellow”). 

Range:  Floating  Point 
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Table  9-10.  Data  Conversion  Attributes  Group  (C) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

INITIAL  VALUE 

C-d\MOT7 

Allowed  when:  C-d\DCN  is  specified 

Eor  Chapter  10  recorders,  this  is  the  initial  engineering 

Range:  Eloating  Point 

unit  value  used  for  mode  7  measurement  change  event 
conditions. 

SAMPLE  RATE 

C-d\SR 

Allowed  when:  C-d\DCN  is  specified 

Enter  the  sample  rate  in  terms  of  samples  per  second. 

Range:  6  characters 

Data  Conversion 

DATE  AND  TIME 

C-d\CRT 

Allowed  when:  C-d\DCN  is  specified 

Date  and  time  calibration  was  released  using  the  format 

REEEASED 

Range:  MM-DD-YYYY-HH-MI-SS 

defined  in  Subsection  9.5.1. 

CONVERSION 

C-d\DCT 

Allowed  when:  C-d\DCN  is  specified 

Define  the  characteristics  of  the  data  conversion. 

TYPE 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

NON 

None 

Engineering  Units: 

PRS 

Pair  Sets 

COE 

Coefficients 

NPC 

Coefficients  [Negative 
Powers  Of  X] 

DER 

Derived 

DIS 

Discrete 

PTM 

PCM  Time 

BTM 

1553  Time 

VOI 

Digital  Voice 

VID 

Digital  Video 

OTH 

Other 

SP 

Special  Processing,  enter  in 
comments 
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Table  9-10.  Data  Conversion  Attributes  Group  (C) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

Engineering  Units  Conversion 

Pair  Sets 

NUMBER  OF  SETS 

C-d\PS\N 

Allowed  when:  C\DCT  is  “PRS”  or  C-d\C01 
is  “Y” 

Specify  the  number  of  pair  sets  provided,  n. 

Required  when:  Allowed 

Range:  2-32 

APPEICATION 

C-d\PSl 

Allowed  when:  C\DCT  is  “PRS” 

Are  the  pair  sets  to  be  used  to  define  a  polynomial  curve 
fit?  If  the  answer  is  no,  then  the  pair  sets  are  to  be  used 
as  a  “table  lookup”  with  linear  interpolation  between  the 
defined  points. 

Range:  Enumeration 

Enumeration 

Description 

Y 

Yes 

N 

No 

Default:  N 

ORDER  OF  FIT 

C-d\PS2 

Allowed  when:  C\PS1  is  “Y” 

Specify  the  order  of  the  curve  fit  to  be  performed,  m.  At 
least  2  pair  sets  must  be  provided,  and  a  maximum  of  32 
pair  sets  may  be  included.  Twelve  or  more  pair  sets  are 
recommended  for  a  fifth  order  fit.  Use  “BE”  for  Best  Fit. 

Required  when:  Allowed 

Range:  1-100  or  “BE” 

TEEEMETRY 

VAEUE 

C-d\PS3-n 

Allowed  when:  C\DCT  is  “PRS”  or  C-d\C01 
is  “Y” 

Telemetry  units  value. 

Required  when:  Allowed 

Range:  Floating  Point 

ENGINEERING 
UNITS  VAEUE 

C-d\PS4-n 

Allowed  when:  C\DCT  is  “PRS”  or  C-d\C01 
is  “Y” 

Engineering  units  value. 

Required  when:  Allowed 

Range:  Floating  Point 

NOTE:  Repeat  the  above  for  the  n  pair  sets. 

Coefficients 

ORDER  OF 

CURVE  FIT 

C-d\CO\N 

Allowed  when:  C\DCT  is  “COE” 

Specify  the  order  of  the  polynomial  curve  fit,  n. 

Required  when:  Allowed 

Range:  1-100 
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Table  9-10.  Data  Conversion  Attributes  Group  (C) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

DERIVED  EROM 
PAIR  SET 

C-d\C01 

Allowed  when:  C\DCT  is  “COE” 

Were  the  coefficients  derived  from  the  pair  set 
calibration  data  provided  (“Y”  or  “N”)?  If  yes,  provide  a 
point  of  contact  in  the  comments. 

Range:  Enumeration 

Enumeration 

Description 

Y 

Yes 

N 

No 

Default:  N 

COEEEICIENT  (0) 

C-d\CO 

Allowed  when:  C\DCT  is  “COE” 

Value  of  the  zero-order  term  (offset). 

Required  when:  Allowed 

Range:  Eloating  Point 

N-TH 

COEEEICIENT 

C-d\CO-n 

Allowed  when:  C\DCT  is  “COE” 

Value  of  the  coefficient  of  the  n*  power  of  x  (first  order 
coefficient  is  the  equivalent  of  bit  weight). 

Required  when:  Allowed 

Range:  Eloating  Point 

NOTE:  Repeat  until  all  n-i-1  coefficients  are  defined. 

Coefficients  (Negative  Powers  o 

FX) 

ORDER 

C-d\NPC\N 

Allowed  when:  C\DCT  is  “NPC” 

Specify  the  order  of  negative  power  coefficients,  n. 

Required  when:  Allowed 

Range:  1-100 

DERIVED  EROM 
PAIR  SET 

C-d\NPCl 

Allowed  when:  C\DCT  is  “NPC” 

Were  the  coefficients  derived  from  the  pair  set 
calibration  data  provided  (“Y”  or  “N”)?  If  yes,  provide  a 
point  of  contact  in  the  comments. 

Range:  Enumeration 

Enumeration 

Description 

Y 

Yes 

N 

No 

Default:  N 

COEEEICIENT  (0) 

C-d\NPC 

Allowed  when:  C\DCT  is  “NPC” 

Value  of  the  zero-order  term  (offset). 

Required  when:  Allowed 

Range:  Eloating  Point 

N-TH 

COEEEICIENT 

C-d\NPC-n 

Allowed  when:  C\DCT  is  “NPC” 

Value  of  the  coefficient  of  the  negative  n*  power  of  x. 

Required  when:  Allowed 

Range:  Eloating  Point 
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Table  9-10.  Data  Conversion  Attributes  Group  (C) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

NOTE:  Repeat  until  all  n-i-1  eoefficients  are  defined.  This  section  describes  the  conversion  equation  v=c0  -i-  cl*(l/x)  -i-  c2*(l/x^)  -i-  ...-i-  cn*(l/x"), 
where  cO,  cl,  c2,. .  .,cn  are  the  coefficients,  x  is  the  telemetry  value,  and  y  is  the  resulting  EU  value. 

Other 

DEFINITION  OF 
OTHER  DATA 
CONVERSION 

C-d\OTH 

Allowed  when:  C\DCT  is  “OTH”  or  “SP” 

Define  other  data  conversion  technique  or  special 
processing  requirement. 

Required  when:  Allowed 

Range:  1000  characters 

Derived  Parameter 

AEGORITHM 

TYPE 

C-d\DPAT 

Allowed  when:  C\DCT  is  “DER” 

Specify  whether  the  algorithm  will  be  given  (in  C- 
d\DPA)  as:  “N”  (Name  of  algorithm).  “A”  (Algorithm). 
See  Appendix  9-E  for  additional  details. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

N 

Name  of  algorithm 

A 

Algorithm 

AEGORITHM 

C-d\DPA 

Allowed  when:  C\ 

DCT  is  “DER” 

Define  the  algorithm  to  be  used  in  deriving  the 
parameter.  See  Appendix  9-E  for  additional  details. 

Required  when:  Allowed 

Range:  1024  characters 

TRIGGER 

MEASURAND 

C-d\DPTM 

Allowed  when:  C\DCT  is  “DER” 

Specify  the  name  of  the  input  measurand  that  triggers  the 
calculation  of  the  derived  parameter. 

Required  when:  Allowed 

Range:  32  characters 

Finks  to:  C-d\DCN 

NUMBER  OF 
OCCURRENCES 

C-d\DPNO 

Allowed  when:  C\DCT  is  “DER” 

Specify  how  many  times  the  trigger  measurand  must 
occur  before  the  calculation  is  done.  Default  is  1. 

Range:  2  characters 

NUMBER  OF 

INPUT 

MEASURANDS 

C-d\DP\N 

Allowed  when:  CVDPAT  is  “N” 

Specify  the  number  of  input  measurands  used  to  derive 
this  parameter. 

Required  when:  Allowed 

Range:  1-100 

MEASURAND  #N 

C-d\DP-n 

Allowed  when:  CVDPAT  is  “N” 

Specify  the  name  of  the  n*  input  measurand. 

Required  when:  Allowed 

Range:  32  characters 

Finks  to:  C-d\DCN 
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Table  9-10.  Data  Conversion  Attributes  Group  (C) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

NOTE:  Continue  until  all  n  measurands  are  defined. 

NUMBER  OF 

INPUT 

CONSTANTS 

C-d\DPC\N 

Allowed  when:  CVDPAT  is  “N” 

Specify  the  number  of  input  constants  used  to  derive  this 
parameter. 

Required  when:  Allowed 

Range:  1-100 

CONSTANT  #N 

C-d\DPC-n 

Allowed  when:  CVDPAT  is  “N” 

Specify  the  value  for  the  n*  constant. 

Required  when:  Allowed 

Range:  Floating  Point 

NOTE:  Continue  until  all  n  constants  are  defined. 

Discrete 

NUMBER  OF 
EVENTS 

C-d\DIC\N 

Allowed  when:  CVDCT  is  “DIS” 

How  many  events  are  associated  with  this  discrete  field, 
n? 

Required  when:  Allowed 

Range:  1-100 

NUMBER  OF 
INDICATORS 

C-d\DICEN 

Allowed  when:  CVDCT  is  “DIS” 

Number  of  indicators:  For  a  PCM  system,  provide  the 
number  of  bits  used  for  this  discrete  set.  For  an  analog 
channel,  provide  the  number  of  levels  used  to  define  this 
discrete  set. 

Required  when:  Allowed 

Range:  1-100 

CONVERSION 

J^TA 

C-d\DICC-n 

Allowed  when:  CVDCT  is  “DIS” 

Telemetry  value,  counts  for  PCM,  percent  of  full  scale 
for  analog. 

Required  when:  Allowed 

i/GF 

Range:  Floating  Point 

PARAMETER 

EVENT 

DEFINITION 

C-d\DICP-n 

Allowed  when:  CVDCT  is  “DIS” 

Define  the  event  for  the  bit  or  bit  field  in  a  word  that 
corresponds  to  a  discrete  event  or  the  percent  full  scale 
value  such  as  switch  on  or  off. 

Required  when:  Allowed 

Range:  240  characters 

NOTE:  Continue  to  c 

efine  the  events  for  each  bit  pattern  or  value  of  the  discrete  measurand. 

PCM  Time 

PCM  TIME  WORD 
FORMAT 

C-d\PTM 

Allowed  when:  CVDCT  is  “PTM” 

Specify  the  PCM  time  word  format  used,  as  defined  in 
Chapter  4  (Section  4.7). 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

H 

High-order  time 

9-152 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  9,  July  2017 


Table  9-10.  Data  Conversion  Attributes  Group  (C) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

E 

Eow-order  time 

M 

Microseeond  time 

1553  Time 

1553  TIME  WORD 
FORMAT 

C-d\BTM 

Allowed  when:  C\DCT  is  “BTM” 

Specify  the  1553  time  word  format  used,  as  defined  in 
Chanter  4  (Section  4.7)  and  Chanter  8  (Section  8.3). 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

H 

High-order  time 

E 

Eow-order  time 

M 

Microsecond  time 

R 

Response  time 

Digital  Voice 

ENCODING 

METHOD 

C-dWOEE 

Allowed  when:  C\DCT  is  “VOI” 

Specify  the  voice  encoding  method  used. 

Required  when:  Allowed 

Range:  Enumeration 

Enumeration 

Description 

CVSD 

Continuously  Variable 

Slope  Delta  modulation 

OTHR 

Other 

DESCRIPTION 

C-dWOED 

Allowed  when:  C\ 

DCT  is  “VOI” 

Specify  the  decoding  algorithm  to  be  used. 

Required  when:  Allowed 

Required  eondition:  When  C\VOI\E  is 
“OTHR” 

Range:  640  eharaeters 

Digital  Video 

ENCODING 

METHOD 

C-d\VID\E 

Allowed  when:  C\DCT  is  “VID” 

Specify  the  video  encoding  method  used. 

Required  when:  Allowed 

Range:  64  eharaeters 
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Table  9-10.  Data  Conversion  Attributes  Group  (C) 

Parameter 

Code  Name 

Usage  Attributes 

Definition 

DESCRIPTION 

C-d\VID\D 

Allowed  when:  C\DCT  is  “VID” 

Specify  the  decoding  algorithm  to  be  used. 

Required  when:  Allowed 

Range:  640  characters 

Comments 

COMMENTS 

C-d\COM 

Allowed  when:  C-d\DCN  is  specified 

Provide  the  additional  information  requested  or  any  other 
information  desired. 

Range:  3200  characters 
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9.5.8  Airborne  Hardware  Attributes  (H) 

The  Airborne  Hardware  Attributes  group  defines  the  specific  configuration  of  airborne 
instrumentation  hardware  in  use  on  the  item  under  test.  This  group  allows  the  same  TMATS  file 
to  describe  the  airborne  hardware  as  well  as  the  telemetry  attributes. 

Specific  information  on  the  structure  and  definition  of  airborne  hardware  attributes  is  not 
included  in  this  standard.  There  are  far  too  many  hardware  systems  to  try  to  define  them  all  in 
one  group.  The  main  purpose  of  identifying  this  group  is  to  reserve  the  “H”  designation  for 
those  instrumentation  organizations  that  choose  to  use  the  TMATS  standard  in  this  way. 


The  only  H  group  attributes  defined  in  this  standard  are  the  following: 

a.  Test  Item  (code  name  H\TA)  -  specifies  the  item  under  test  and  ties  the  H  group  to  the  G 
group. 


b.  Airborne  System  Type  (code  name  H\ST-n)  -  identifies  the  airborne  systems  being 
described  in  the  current  file  and  determines  how  the  rest  of  the  attributes  in  the  H  group 
will  be  interpreted. 


NOTE 


For  anyone  wishing  to  define  an  H  group,  it  is  strongly  recommended  that  the 
conventions  laid  out  in  this  standard  be  followed.  The  resultant  document 
should  maintain  the  look  and  feel  of  this  standard  for  consistency. 


9.5.9  Vendor-Specific  Attributes  (V) 

The  Vendor-Specific  Attributes  group  provides  information  that  is  specific  to  a  vendor. 
This  group  allows  the  TMATS  file  to  include  information  about  a  particular  vendor’s  equipment 
in  use  during  a  test.  Detailed  information  about  specific  vendors’  equipment  is  not  included  in 
this  standard. 


The  only  V-group  attributes  defined  in  this  standard  are  the  following. 

a.  Data  Source  ID  (code  name  V-x\ID)  -  specifies  the  Data  Source  ID  consistent  with  the 
General  Information  group  and  ties  the  V  group  to  the  G  group. 

b.  Vendor  Name  (code  name  V-x\VN)  -  a  three-character  acronym  that  identifies  the 
specific  vendor  and  determines  how  the  rest  of  the  attributes  in  the  V  group  are 
interpreted. 

All  other  code  names  for  vendor- specific  attributes  will  have  the  form: 

V -x\acr\attribute-string 


where:  acr  is  the  three-character  acronym  identifying  a  specific  vendor. 


attribute-string  is  any  attribute  that  applies  to  this  vendor. 


NOTE 


For  anyone  wishing  to  define  a  V  group,  it  is  strongly  recommended  that  the 
conventions  laid  out  in  this  standard  be  followed.  The  resultant  document 
should  maintain  the  look  and  feel  of  this  standard  for  consistency. 
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9.5.10  TMATS  extension  Attributes  (X) 

The  TMATS  may  be  extended  using  X  attributes.  The  format  is  described  below: 

X-x\  ORGANIZATION  \ORIGCODE\EXTENSION_CODE-i-]-m-n:NahiQ\ 

Everything  to  the  right  of  ORGANIZATION  that  matches  an  existing  TMATS  code  is 
used  to  associate  the  extension  with  an  existing  object  defined  by  the  TMATS  file. 

The  ORIGCODE  contains  the  original  group  identifier  (i.e.,  G,D,P,  etc.)  followed  by  a 
“\”  and  the  original  code  that  is  to  be  extended  (may  include  more  “\”  characters,  but  no  The 
EXTENSIONjCODE  identifies  the  specific  extension  and  shall  be  unique  (i.e.,  not  overlapping 
any  existing  TMATS  code  name).  The  value  of  “-x”  must  match  the  first  level  index  (P-x,  etc.) 
value  and  the  “-i-j”  (the  number  of  indexes  defined  by  the  original  code)  must  match  the  same 
number  of  indexes  in  this  extension  code.  The  remaining  “-m-n”  values  are  unique  to  the 
extension. 

For  example,  to  extend  a  D  section  measurement: 

D-1\MN-1-2:MEAS1; 

To  add  a  new  extension  code  name  for  Sensor  Gain,  the  following  would  define  the 
extension: 


X- 1  \MYORG\D\MN\SGAIN- 1-2:10.75; 

In  this  example,  the  -1  in  the  “X-1”  and  “-1-2”  corresponds  to  the  “-1”  and  “-1-2”  in  the 
original  “D-l\MN-l-2”  code  word. 

If  the  extension  has  more  indexes  than  the  original  code,  then  the  indexes  of  the  original 
code  link  to  the  same  number  of  left  most  indexes  of  the  extension  code. 

The  value  of  ORGANIZATION  should  be  a  unique  name  that  identifies  the  organization 
that  defined  the  extension. 

The  advantage  of  this  extension  is  that  software  that  is  processing  the  TMATS  will  know 
that  these  codes  refer  to  a  particular  item  in  the  file  (like  a  measurement  or  recorder).  For 
software  that  recognizes  the  codes,  it  can  process  them.  Otherwise  they  can  be  ignored. 

If  the  file  is  being  edited  by  a  TMATS  editor,  it  would  notice  the  association  and  preserve 
it  even  if  the  editor  doesn’t  know  what  the  code  means.  Thus  if  the  measurements  were  re¬ 
numbered  and  the  index  was  1-5  instead  of  1-2,  the  extension  code  could  be  updated  to  preserve 
the  link. 

The  values  of  “x”  in  “X-x”  are  not  necessarily  contiguous.  The  “x”  values  must  match 
the  index  of  the  original  code  word  therefore  no  new  values  may  be  added. 

9.6  Data  Display  Standard:  Data  Display  Markup  Language 

The  standard  format,  DDME,  has  been  developed  to  describe  commonly  used  data 
displays.  This  DDME  standard  exists  only  as  a  collection  of  XSD  files;  it  does  not  exist  in  the 
TMATS  code  name  format  described  in  Section  9^.  The  DDME  schema  can  be  found  here. 
Additionally,  a  graphical  depiction  of  the  schema  in  hypertext  markup  language  (HTME)  format 
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is  available  here.  The  HTML  files  are  very  large  and  will  take  time  to  download.  The  following 
paragraphs  explain  the  purpose,  objectives,  and  structure  of  DDML,  and  define  the  global 
elements  in  the  schema. 

9.6.1  Data  Display  Markup  Language  Purpose  and  Objectives 

The  purpose  of  DDML  is  to  serve  as  the  neutral  interchange  language  between  data 
display  languages  supported  by  different  vendors.  Built  on  XML,  DDML  has  been  designed 
with  the  following  objectives  in  mind: 

a.  To  include  a  standard  terminology  for  describing  data  display  components; 

b.  To  be  robust  and  highly  expressive  in  order  to  accommodate  any  data  display  language; 

c.  To  be  highly  unified  and  not  a  loose  grouping  of  vendor  formats. 

9.6.2  Data  Display  Markup  Language  Layered  Structure 

The  DDML  is  built  off  of  a  layered  structure  as  shown  on  the  left  of  Figure  9-11  below. 
This  structure  is  parallel  to  a  typical  software  layered  architecture  composed  of  graphics 
resources,  visualization  and  user  interfaces,  information  management,  and  persistence  modules 
as  shown  on  the  right  side  of  Figure  9-11. 


DDML  Layers 

Typical  Software  Layer 
(e.g.,  Model-5’ievv 
Architecture) 

Graphics  Resources 
(Positions,  Color,  etc.) 

Graphics  Resources 
(Controls,  Color,  etc.) 

Q 

Dynamics 

User  Interfaces 
(Rendering,  Display,  etc.) 

c 

Data  Variables  and 
Derived  Data 

Information  Management 
(Objects,  Variables,  etc.) 

Data  Sources 

Persistance 

(Load,  Save,  etc.) 

Figure  9-11.  Layered  Structure  of  DDML 


Parallel  to  the  typical  software  modules,  DDML  is  also  composed  of  layers  (as  depicted 
above  in  Figure  9-11)  and  as  described  below. 

a.  Graphics  Resources.  This  layer  is  similar  to  “graphics  resources”  of  a  typical  software 
tool.  In  DDML,  this  layer  includes  the  visual  components  of  a  data  display  system  such 


9-157 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  9,  July  2017 


as  sliders,  plots,  and  strip  charts  as  well  as  low-level  graphic  elements  such  as  lines, 
rectangles,  etc.  Basic  graphical  shapes  are  modeled  using  a  World  Wide  Web 
Consortium  (W3C)  recommended  format  called  Scalable  Vector  Graphics  (SVG). 

b.  Dynamics.  The  dynamics  layer  handles  the  behavior  of  an  object.  It  manages  the  rules 
and  the  variable  instances  attached  to  an  object. 

c.  Data  Variables.  Data  variables  are  the  links  between  the  objects  and  the  data  sources. 
Data  variables  can  be  atomic  or  derived.  Derived  variables  may  use  other  derived  or 
atomic  variables  in  a  mathematical  expression. 

d.  Data  Sources.  The  last  layer  of  the  DDML  architecture  is  the  Data  Sources  layer.  This 
layer  handles  various  data  sources  such  as  text  files.  Open  Database  Connectivity 
(ODBC),  network  ports,  and  ports  on  data  acquisition  cards. 

At  each  layer,  the  parameters  used  to  describe  each  DDML  element  are  divided  into  two 
groups:  DDML  sub-elements  and  custom  parameters.  The  DDML  sub-elements  make  up  the 
most  common  and  most  necessary  pieces  of  information  needed  to  represent  each  element.  They 
are  stored  as  named  sub-elements  in  DDML.  Custom  parameters  are  used  to  store  any  vendor- 
specific  information  that  is  not  explicitly  defined  as  a  DDML  sub-element.  These  parameters  are 
stored  as  DDML  “param”  elements. 


9.6.3  Data  Display  Markup  Language  Global  Element  Glossary 

The  DDML  element  names  and  descriptions  can  be  seen  in  Table  9-11. 


Table  9-11.  Data  Display  Markup  Language  Global  Element  Glossary 

Element  Name 

Description 

mathml:  apply 

Defined  in  the  mathml  schema  and  used  as  a  sub-element  of  variable  in 
DDML,  defines  a  variable  as  a  function  of  other  variables. 

axis 

A  sub-element  of  a  display  object,  represents  an  axis  of  any  chart-type 
display  object.  It  has  a  sub-element  axisType  that  can  be  one  of  two 
values:  VALUE  or  TIME.  Other  sub-elements  allow  the  setting  of  min 
and  max  values,  colors,  grid  line  properties,  etc. 

barchart 

A  display  object  that  shows  one  or  more  variables  as  vertical  or  horizontal 
bars  whose  lengths  correspond  to  the  values. 

button 

A  display  object  that  consists  of  an  image  or  icon  that,  when  clicked,  can 
assign  a  value  to  a  variable. 

color 

A  commonly  used  sub-element  of  many  DDME  elements,  it  simply 
specifies  the  color  of  its  parent  object.  All  colors  in  DDME  are  stored  as 
base- 10  integers  that  are  encoded  as  OxRRGGBB. 

comparisonOperator 

Used  in  rules,  defines  the  comparison  between  two  values.  Can  be  either 

GT  (greater  than),  ET  (less  than),  GTE  (greater  than  or  equal),  ETE  (less 
than  or  equal),  EQ  (equal),  or  NEQ  (not  equal). 

custom_parameters 

A  sub-element  of  a  display  object,  serves  as  the  parent  element  of  a  group 
of  param  elements  that  specify  all  of  the  custom  (vendor-specific) 
parameters  for  a  particular  display  object. 
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Table  9-11.  Data  Display  Markup  Language  Global  Element  Glossary 

Element  Name 

Description 

data_source 

A  pool-level  data  source  that  is  available  for  use  by  any  of  the  variables  in 
the  variable  pool. 

data_source_pool 

Contains  data_source  child  elements  representing  all  of  the  data  sources 
used  by  the  various  objects  in  the  DDML  file.  Information  about  all  data 
sources  (files,  db  connections,  etc.)  is  kept  in  the  data  source  pool. 

ddml 

Root  element  of  a  DDML  file  describing  a  collection  of  data  displays. 

dial 

A  display  object  that  consists  of  a  circular  or  arc  value  axis  and  some  sort 
of  marker  or  needle  that  points  to  the  current  value  along  this  axis. 

Example:  a  gauge  or  a  compass. 

display_objects 

A  sub-element  of  a  model,  serves  as  a  container  for  all  of  the  display 
objects  in  that  model. 

dynamics 

A  set  of  variable  uses  and  rules  used  to  define  the  dynamic  behavior  of  a 
display  object.  The  dynamicType  sub-element  describes  the  dynamic 
behavior  while  the  variable_use  and  rules  child  elements  define  how 
variable  values  affect  that  behavior.  A  dynamicType  of  “builtin”  is  used 
for  display  objects  that  have  implicit  dynamic  behavior,  such  as  charts  and 
sliders.  Other  possible  values  of  dynamicType  include:  visibility,  text, 
subdrawing,  scale,  scaleY,  scaleX,  rotate,  relativeMoveY,  relativeMoveX, 
pathMove,  lineWidth,  lineStyle,  foregroundColor,  fillUp,  fillRight,  fillLeft, 
fillDown,  fillEffect,  curveType,  blink,  backgroundColor,  arcDirection, 
absoluteMoveX,  absoluteMoveY,  fillColor,  edgeColor. 

else 

Part  of  a  rule,  specifies  what  to  do  if  the  criteria  specified  in  the  if  element 
are  false.  The  else  element  can  be  the  parent  of  one  or  more  additional 
rules,  or  can  just  specify  a  value  or  variable  reference. 

frequencyplot 

A  display  object  that  is  a  chart  in  the  frequency  domain. 

frequencyresponse 

A  display  object  that  is  a  graph  consisting  of  two  value  axes  (frequency 
and  magnitude)  plotted  against  a  single  frequency  axis. 

grid 

A  table.  The  grid  element  is  used  to  group  several  display  objects 
(including  other  grids)  together  in  a  tabular  layout.  Each  display  sub¬ 
object’s  location  in  the  grid  is  specified  with  its  gridRow  and  gridColumn 
elements. 

hud 

A  display  object  that  resembles  a  typical  aircraft  heads-up  display  that 
consists  of  three  vertical  axes  (typically  used  for  velocity,  pitch,  and 
altitude)  and  one  horizontal  axis  (typically  for  heading).  The  center 
vertical  axis  rotates  according  to  a  fifth  variable  (typically  roll).  The 
variable_uses  in  the  dynamics  section  are  applied  in  this  order:  center 
vertical  axis  rotation  (roll),  center  vertical  axis  (pitch),  horizontal  axis 
(heading),  right  vertical  axis  (altitude),  left  vertical  axis  (velocity). 

if 

Part  of  a  rule,  specifies  a  comparison  between  the  current  variable  and 
some  value. 
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Table  9-11.  Data  Display  Markup  Language  Global  Element  Glossary 

Element  Name 

Description 

map 

An  area  of  a  model  that  displays  longitude/latitude  map  info.  The 
coordinates  of  all  child  objects  of  a  map  are  in  decimal  latitude/longitude 
values.  For  distance  attributes  (e.g.,  a  circle’s  radius),  degrees  latitude  are 
used  as  the  measurement  unit. 

model 

A  container  for  data  displays.  Typically  interpreted  as  a  single  screen  or 
“page”  of  display  objects.  The  model  object  defines  its  own  coordinate 
system  with  the  minX,  minY,  maxX,  maxY,  xDirection,  and  yDirection 
sub-elements.  All  sub-objects  of  a  model  are  specified  in  coordinates  that 
conform  to  the  system  defined  by  the  model. 

object 

A  generic  display  object.  An  “object”  can  be  any  display  object  not 
specified  in  the  DDML  definition,  or  can  be  used  as  the  top-level  element 
in  a  group  of  sub-objects. 

param 

Used  to  specify  any  parameter  of  a  DDML  element  that  is  not  explicitly 
specified  elsewhere  in  the  schema.  These  are  commonly  referred  to  as 
“custom  parameters”  and  are  mostly  used  for  vendor- specific  information. 

piechart 

A  circular  display  object  that  shows  the  values  of  multiple  variables  as  a 
percentage  slice  of  their  sum. 

project 

A  collection  of  models. 

radialchart 

A  display  object  that  represents  variable  values  as  distances  outward  from 
a  central  point.  A  radial  chart  consists  of  two  axes:  a  linear  value  axis  and 
a  circular  axis.  The  circular  axis  can  be  either  a  time  axis  or  a  value  axis. 
The  type  of  the  circular  axis  is  controlled  by  its  axisType  sub-element, 
which  can  have  a  value  of  either  “TIME”  or  “VALUE”.  If  the  value  is 
“VALUE”,  then  a  series  of  xyPair  objects  will  specify  how  the  variables 
are  paired.  In  each  of  these  xyPairs,  the  X- value  corresponds  to  the  value 
in  the  circular  axis  direction,  and  the  Y-value  corresponds  to  the  value  in 
the  radial  axis  direction. 

rule 

Specifies  a  change  in  a  property  (e.g.,  color,  visibility)  when  a  variable 
reaches  a  certain  value  or  range  of  values.  The  ranges  of  values  and 
resulting  property  values  are  specified  with  if,  then,  and  else  child 
elements. 

rules 

The  parent  element  of  a  group  of  rule  elements 

slider 

A  display  object  that  consists  of  some  kind  of  indicator  or  icon  that  slides 
along  a  single  value  axis.  A  slider  can  be  vertical  or  horizontal.  Example: 

A  “gauge”  in  Range  View  or  a  “fader”  in  Data  Views. 

stripchart 

A  display  object  that  is  essentially  a  line  graph  that  plots  values  vs.  time 
along  a  scrolling  “paper”  grid.  A  stripchart  can  be  vertical  or  horizontal, 
and  can  scroll  in  any  of  the  four  directions  (up,  down,  left,  right).  This  is 
controlled  by  the  scrollDirection  sub-element.  The  scrollDirection  element 
refers  to  the  direction  that  the  paper  or  background  scrolls.  Eor  example, 
in  a  DataViews  horizontal  strip  chart,  the  paper  scrolls  to  the  left  while 
new  values  are  plotted  at  the  right  edge  of  the  graph.  Thus,  the 
scrollDirection  is  “left”. 
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Table  9-11. 

Data  Display  Markup  Language  Global  Element  Glossary 

Element  Name 

Description 

svg:svg 

SVG  is  a  W3C  recommendation  and  is  defined  in  its  own  schema.  In 
DDML,  the  <svg>  element  is  used  as  a  sub-element  of  <object>  to  define  a 
display  object  in  terms  of  the  basic  shapes  of  which  it  is  composed. 

textual 

A  display  object  used  for  representing  text  and  labels,  including  both  static 
and  dynamic  text  (such  as  annunciators).  If  the  text  is  dynamic,  the 
valuePosition  sub-element  specifies  where  the  dynamic  value  is  in  relation 
to  the  static  label.  Use  valuePosition=“center”  if  there  is  no  label.  The 
valueFormat  sub-element  is  a  C  printf-style  format  string  that  specifies  the 
format  of  the  dynamic  value.  For  example  valueFormat  =  “%4.2f  ’ 
indicates  that  the  value  should  be  output  as  a  floating-point  value  with  a 
maximum  width  of  4  and  with  2  decimal  places. 

then 

Part  of  a  rule,  the  then  element  specifies  the  value  to  set  the  attribute  to  if 
the  criteria  specified  in  the  if  element  is  true.  The  then  element  can  specify 
either  the  desired  value  or  a  reference  to  a  variable  containing  the  desired 
value. 

variable 

A  pool-level  data  variable  that  is  available  for  use  by  any  of  the  display 
objects  in  the  DDML  file. 

variable_pool 

Contains  variable  child  elements  representing  all  of  the  variables  used  by 
the  various  display  objects  in  the  DDML  file. 

variable_use 

A  child  of  the  dynamics  element,  variable_use  is  used  to  specify  which 
variable  from  the  variable  pool  is  used.  The  pool_ref  attribute  must  refer 
to  the  ID  attribute  of  a  variable  element  from  the  variable pool. 

xychart 

A  display  object  that  is  a  line  or  xy  scatter  plot  of  variables  in  the  y  axis  vs. 
other  variables  in  the  x  axis.  The  x,y  variable  pairs  are  specified  with  the 
xyPair  sub-elements. 

xyPair 

A  sub-element  of  certain  display  objects,  it  describes  how  a  chart’s 
variable_use  items  are  paired.  Each  xVar  and  yVar  sub-element  must  refer 
to  the  ID  of  a  variable_use  element  in  the  display  object’s  dynamics 
section. 

9.7  Instrumentation  Hardware  Abstraction  Language 

The  IHAL  is  a  standard  for  describing  and  interacting  with  instrumentation  hardware  in  a 
vendor-neutral  way.  The  IHAL  was  reviewed  and  adopted  into  IRIG  106  to  serve  the  purpose 
originally  intended  for  the  Airborne  Hardware  Attributes  (H)  group  described  in  Subsection 
9.5.8,  which  has  never  been  implemented.  The  IHAL  standard  consists  of  both  an  XML-based 
language  and  an  application  programming  interface  (API)  specification,  each  of  which  are 
explained  in  greater  detail  below. 

The  IHAL  language  standard  exists  only  as  an  XML  schema;  it  does  not  exist  in  the 
TMATS  code  name  format  described  in  Section  9^.  The  IHAL  XML  language  schema  consists 
of  a  collection  of  XSD  files  that  define  the  structure  of  valid  IHAL  documents.  The  schemas  are 


9-161 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  9,  July  2017 


available  here.  Additionally,  a  graphical  depiction  of  the  schema  in  HTML  format  is  available 
here.  The  HTML  files  are  very  large  and  will  take  time  to  download. 

9.7.1  Usage  of  External  Schemas  in  IHAL 

The  IHAL  XML  schema  makes  use  of  three  external  XML  schemas  for  describing 
concepts  outside  the  scope  of  IHAL,  such  as  data  formats  and  engineering  units.  These  schemas 
are  not  included  with  the  IHAL  schema  and  must  be  retrieved  from  the  organization  that 
produces  them.  Table  9-12  lists  these  external  schemas  and  the  versions  required  for  this  release 
of  IHAL. 


Table  9-12.  IHAL  External  Schemas 

Standard 

Version 
used  by 
IHAL 

Global  Types/Sub¬ 
schemas  used  by  IHAL 

Organization’s  URL 

Metadata  Description 
Language  (MDL) 

0.8.12 

DerivedUnitType 

MeasurementsType 

DataStreamsType 

http  ://w  w  w .  inetprogram.  or  g 

TMATS  -  XML  Schema 

106-17 

TmatsPGroup.xsd 

TmatsRGroup.xsd 

htto://www.  wsmr.armv.mil/ 

RCC  site/Documents/Refere 

nces/tmats 

extensible  Instrumentation 
Definition  Markup 

Language  (XidML) 

3.0 

Network-TransportType 

http://www.xidml.org/ 

9.7.2  What  is  the  Instrumentation  Hardware  Abstraction  Language? 

The  central  concept  in  IHAL  is  the  configurable  attributes  (i.e.,  settings)  that  each  device 
exposes  to  the  user;  however,  IHAL  is  also  capable  of  describing  the  environmental  and  physical 
attributes  of  each  device,  such  as  its  size,  shape,  and  operating  conditions. 

The  IHAL  describes  instrumentation  hardware  at  two  levels. 

a.  The  “pool”  level  describes  hardware  according  to  its  capabilities  and  configurability. 

The  information  in  the  IHAL  pool  is  similar  to  the  information  found  in  a  device’s 
marketing  or  engineering  data  sheet.  A  good  way  to  think  of  the  pool  is  to  understand 
that  each  device  in  the  pool  can  be  uniquely  identified  by  its  model  number. 

b.  The  “use”  level  describes  a  specific  configuration  of  instrumentation  hardware.  At  the 
use  level,  devices  from  the  pool  are  put  into  a  specific  use.  That  is,  they  are  connected  to 
other  devices,  and  their  configurable  attributes  are  set  to  specific  values.  A  good  way  to 
think  of  the  use  level  is  to  understand  that  each  device  at  this  level  can  be  uniquely 
identified  by  its  serial  number. 

9.7.3  What  is  the  IHAL  API? 

The  IHAL  vendor  web  services  API  enables  IHAL  to  be  used  not  only  as  a  language  for 
describing  instrumentation  hardware,  but  also  as  a  command  and  query  language  for  configuring 
instrumentation  hardware.  The  API  defines  a  set  of  functions  that  an  instrumentation  hardware 
vendor  can  implement  to  provide  access  to  their  configuration  engine  to  external  users  and 
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applications.  All  inputs  and  outputs  to  the  functions  are  properly  formatted  IHAL  XML 
documents. 

Implementing  this  API  allows  vendors  to  expose  the  functionality  of  their  configuration 
engines  in  a  vendor-neutral  way,  without  disclosing  the  inner  workings  of  their  proprietary 
configuration  logic.  In  this  way,  vendor-neutral,  3rd-party  applications  can  be  developed  to 
configure  the  hardware  of  any  vendor  who  implements  the  IHAL  API.  The  developers  of  such 
3rd-  (or  1st-)  party  applications  need  not  understand  the  inner  workings  of  each  vendor’s 
configuration  engine. 

9.7.4  How  Can  IHAL  Be  Used? 

The  potential  uses  of  IHAL  fall  into  two  major  categories:  1)  IHAL  as  a  description 
language,  and  2)  IHAL  as  a  command  language. 

9.7.4. 1  IHAL  as  a  Description  Language 

As  a  vendor-neutral,  human-readable  language  for  describing  instrumentation  hardware, 
IHAL  provides  a  means  for  storing  a  permanent  record  of  the  devices  used  during  a  test  and  their 
settings  during  that  test.  This  description  will  remain  readable  and  relevant  even  if  the  hardware 
vendors  radically  change  their  file  formats  or  cease  to  exist. 

Additionally,  providing  such  descriptions  enables  the  development  of  vendor-neutral 
tools.  The  capabilities  of  these  tools  can  range  anywhere  from  simple  visualization  (e.g., 
instrumentation  network  and  configuration  visualization)  to  complex  automated  reasoning  (e.g., 
automatically  selecting  and  configuring  devices  from  multiple  vendors  based  on  user-defined 
requirements). 

9.7. 4. 2  IHAL  as  a  Command  Language 

The  IHAL  constructs  that  describe  the  current  configuration  of  a  device  can  also  be  used 
to  issue  a  command  to  the  device  to  change  its  configuration.  When  combined  with  the  API 
(described  above),  this  feature  of  IHAL  enables  multi- vendor  instrumentation  configuration  from 
a  single  user  interface  without  requiring  vendors  to  share  knowledge  about  the  internal  workings 
of  their  configuration  engines. 

9.7.5  IHAL  Glossary 

Below  is  an  alphabetical  list  of  definitions  of  key  elements  in  the  IHAL  XML  language. 

A 

accelerometer:  A  specialization  of  the  “transducer”  element  for  describing  accelerometers 
(pool-level). 

analogSignalConditioningCard:  A  specialization  of  the  “card”  element  for  describing  analog 
signal  conditioning  cards  (pool-level). 

analogSignalConditioningChannel:  A  specialization  of  the  “customHardwareChannel” 
element  for  describing  analog  signal  conditioning  channels  (pool-level). 

analogSignalConditioningFunction:  A  specialization  of  the  “customFunction”  element  for 
describing  analog  signal  conditioning. 

analogSignalFilterFunction:  A  specialization  of  the  “customFunction”  element  for  describing 
analog  signal  filtering  (pool-level). 
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analogToDigitalConversionFunction:  A  specialization  of  the  “customFunction”  element  for 
describing  analog-to-digital  conversion. 

B 

bridgeSensor:  A  specialization  of  the  “transducer”  element  for  describing  bridge  sensors  (pool- 
level). 

busMonitorCard:  A  specialization  of  the  “card”  element  for  describing  bus  monitor  cards. 

busMonitorChannel:  A  specialization  of  the  “customHardwareChannel”  element  for 
describing  bus  monitor  channels  (pool-level). 

busMonitorChannelUse:  A  specialization  of  the  “channelUse”  element  for  bus  monitors.  This 
element  includes  an  additional  construct  for  defining  a  dataStreamUse  associated  with  the 
channel. 

busMonitorFunction:  A  specialization  of  the  “customFunction”  element  for  describing  bus 
monitoring  (pool-level). 

C 

calibrationTable:  A  use-level  element  for  describing  the  calibration  table  associated  with  a 
particular  transducer  or  other  instrument. 

card:  A  specialization  of  the  “instrument”  element  for  describing  cards.  A  card  in  IHAL  is  an 
instrument  that  cannot  operate  stand-alone.  It  must  be  connected  to  another  instrument  in 
order  to  function. 

channelUse:  A  specific  implementation  of  a  channel  from  the  instrument  pool.  The  channelUse 
description  references  a  channel  from  the  pool,  specifies  a  specific  channel  number,  and 
assigns  values  to  settings  on  that  channel. 

chargeAmplifierSensor:  A  specialization  of  the  “transducer”  element  for  describing  charge 
amplifier  sensors  (pool-level). 

configuration:  Container  for  multiple  instrumentation  graphs.  Defines  a  single  configuration  or 
project. 

connection:  A  use-level  element  used  to  describe  a  connection  between  two  instruments  in  an 
instrumentationGraph. 

currentExcitationFunction:  A  specialization  of  the  “customFunction”  element  for  describing 
current  excitation  (pool-level). 

currentUoopOutputSensor:  A  specialization  of  the  “transducer”  element  for  describing  current 
loop  output  sensors  (pool-level). 

customAttribute:  A  pool-level  element  for  defining  a  generic  attribute  associated  with  a 

function.  Each  attribute  may  be  either  configurable  or  fixed,  and  may  be  either  numeric, 
string.  Boolean,  or  reference.  If  configurable,  the  attribute  element  will  define  which 
values  are  valid.  Each  specialized  function  description  in  IHAE  will  contain 
specializations  of  the  “customAttribute”  element  for  specific  attributes  such  as  “gain”, 
“offset”,  etc. 
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customFunction:  A  pool-level  element  for  defining  generic  instrumentation  functions  that  don’t 
fit  into  one  of  the  specific  specializations.  A  function  may  be  composed  of  0  or  more 
attributes  and  0  or  more  sub-functions. 

customHardwareChannel:  A  pool-level  element  for  describing  a  generic  hardware  channel 
that  does  not  fit  into  any  of  the  specific  specializations.  A  channel  contains  a 
“multiplicity”  element  that  defines  how  many  identical  channels  the  device  has.  A 
channel  is  composed  of  one  or  more  functions. 

D 

dataRecorder Function:  Specialization  of  the  “customFunction”  element  (pool-level).  This  is 
a  channel-level  function  for  describing  the  recording  of  data  from  a  specific  source.  See 
also  recorderReproducerFunction. 

dataRecordingChannel:  Specialization  of  the  “customHardwareChannel”  element  for 
describing  a  data  recorder  channel  (pool-level). 

dataStreamPool:  Contains  the  global  list  of  data  streams  and  buses.  This  element  makes  use  of 
constructs  from  the  integrated  Network  Enhanced  Telemetry  (iNET)  program’s  MDE. 

dataStreamUse:  A  use-level  element  used  to  define  which  measurements  from  a  data  stream 
are  to  be  sampled  by  a  bus  monitor. 

dau:  A  specialization  of  the  “instrument”  element  for  describing  data  acquisition  units  (pool- 
level). 

dauFunction:  Specialization  of  the  “customFunction”  element  for  describing  the  functions 
performed  by  a  data  acquisition  unit  (pool- level). 

E 

errorList:  Top-level  container  for  the  IHAE  error  schema.  An  errorEist  may  be  returned  as  a 
response  to  any  API  function  call. 

F 

formatUse:  A  specific  implementation  of  a  data  format  from  the  instrument  pool.  The 

formatUse  element  references  a  data  format  from  the  pool,  specifies  a  format  number, 
assigns  values  to  settings  associated  with  that  format,  and  defines  the  measurements 
encoded  in  the  format. 


H 

highLevelVoltageSensor:  A  specialization  of  the  “transducer”  element  for  describing  high- 
level  voltage  sensors  (pool-level). 

I 

ihal:  The  top-level  element  in  a  complete  IHAE  description 

instrument:  A  pool-level  element  for  describing  a  device  that  does  not  fit  into  one  of  the 

specific  specializations.  The  pool-level  instrument  element  defines  the  physical  attributes 
of  the  hardware,  the  functionality  it  provides,  and  the  settings  available. 
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instrumentationGraph:  A  set  of  interconnected  instrumentation  hardware  (instrumentUse 
elements).  Separate  instrumentationGraph  elements  could  be  used  to  describe  the 
airborne  system  vs.  the  ground  system,  for  example. 

instrumentPool:  Container  for  all  pool-level  device  descriptions.  The  instrumentPool  contains 
descriptions  of  all  available  instruments. 

instrumentUse:  A  specific  implementation  of  an  instrument  from  the  pool.  The  instrumentUse 
description  references  an  instrument  from  the  pool  and  assigns  specific  values  to  settings. 

L 

IvdtrvdtSensor:  A  specialization  of  the  “transducer”  element  for  describing  linear/rotary 
variable  differential  transformers  (pool-level). 

M 

masterControllerFunction:  Specialization  of  the  “customFunction”  element  for  describing  the 
functionality  of  a  master  controller  (pool-level). 

measurementPool:  Contains  a  global  list  of  measurements. 

P 

potentiometricVoltageDivider:  A  specialization  of  the  “transducer”  element  for  describing 
potentiometric  voltage  dividers  (pool-level). 

programmingStatus:  A  use-level  element  that  describes  the  current  status  of  programming  the 
current  configuration  to  the  physical  hardware.  Values  may  be  either  “COMPLETE”, 
“IN_PROGRESS”,  “ERROR”,  or  “NOT_STARTED”. 

R 

recorderReproducer:  A  specialization  of  the  “instrument”  element  for  describing  a 
recorder/reproducer  (pool- level) . 

recorderReproducerFunction:  A  specialization  of  the  “customFunction”  element  for 
describing  the  function  of  recording/reproducing  data  associated  with  one  or  more 
channels  to/from  some  medium. 

restrictedAttribute:  A  use-level  element  that  redefines  the  set  of  valid  values  for  a  configurable 
attribute  from  the  pool.  Restricted  attributes  are  used  whenever  the  valid  values  for  a 
setting  change  as  a  result  of  the  current  configuration. 

resistanceSensor:  A  specialization  of  the  “transducer”  element  for  defining  resistance  sensors 
(pool-level). 

rtdSensor:  A  specialization  of  the  “transducer”  element  for  describing  resistance  temperature 
detectors  (pool-level). 

S 

setAttribute:  A  use-level  element  that  assigns  a  value  to  a  configurable  attribute  from  the  pool. 

statusDataFunction:  Specialization  of  the  “customFunction”  element  for  describing  the 
function  of  emitting  status  words  (pool-level). 
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strainGauge:  A  specialization  of  the  “transducer”  element  for  describing  strain  gauges  (pool- 
level). 

sstDataEncoderFunction:  A  specialization  of  the  “customFunction”  element  for  describing  a 
serial  streaming  telemetry  (SST)  data  encoder. 

sstDataFormat:  Pool-level  concept  for  describing  an  SST  format  that  may  be  created  by  an 

instrument.  Formats  in  IHAL  are  similar  to  channels  in  that  they  have  a  multiplicity  and 
are  composed  of  functions. 

sstFormatUse:  A  specialization  of  the  “formatUse”  element  for  describing  PCM  output 
formats.  sstFormatUse  makes  use  of  TMATS  XML  constructs. 


thermistor:  A  specialization  of  the  “transducer”  element  for  describing  thermistors  (pool-level). 

thermocouple:  A  specialization  of  the  “transducer”  element  for  describing  thermocouples 
(pool-level). 

tmNSDataEncoderFunction:  Specialization  of  the  “customFunction”  element  for  describing 
the  functionality  of  a  Telemetry  Network  Standard  (TmNS)  data  encoder  (pool-level). 

tmNSDataFormat:  Pool-level  concept  for  describing  a  TmNS  data  format  that  may  be  created 
by  an  instrument.  Formats  in  IHAL  are  similar  to  channels  in  that  they  have  a 
multiplicity  and  are  composed  of  functions. 

transducer:  A  specialization  of  the  “instrument”  element  for  describing  generic  transducers 
(pool-level) 

U 

unitsPool:  Container  for  a  global  list  of  engineering  units.  Units  can  be  built  by  combining 
other  units  and  SI  units.  Unit  descriptions  make  use  of  constructs  from  the  iNET 
program’s  MDL. 

V 

voltageAmplificationFunction:  A  specialization  of  the  “customFunction”  element  for 
describing  voltage  amplification  (pool-level). 

voltageExcitationFunction:  A  specialization  of  the  “customFunction”  element  for  describing 
voltage  excitation  (pool-level). 

X 

xidMLNetworkDataEncoderFunction:  A  specialization  of  the  “customFunction”  element  for 
describing  the  functionality  of  a  non-TmNS  network  data  encoder  (pool-level). 

xidMLNetworkDataFormat:  Pool-level  concept  for  describing  a  non-TmNS  network  data 

format  that  may  be  created  by  an  instrument.  Formats  in  IHAL  are  similar  to  channels  in 
that  they  have  a  multiplicity  and  are  composed  of  functions. 

xidMLNetworkFormatUse:  A  specialization  of  the  “formatUse”  element  for  describing  non- 
TmNS  network  data  formats.  This  element  makes  use  of  constructs  from  XidML. 
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9.7.6  Complete  IHAL  API  Specification 

9 .7 . 6 . 1  API  Implementation  Requirements 

The  IHAL  API  must  be  implemented  as  a  RESTful  web  service.  All  functions  must  have 
a  common  base  path  (e.g.,  http://10.10.1.1:8080/ihalapi/).  This  base  path  is  referred  to  as 
“<Vendor  API  Location>“  in  this  document. 

All  inputs  are  provided  as  the  payload  of  the  function  call,  with  no  named  parameters  or 
URL  encoding.  That  is,  inputs  will  NOT  be  part  of  the  URL  (e.g.,  http://.../?ihal=<ihal>...  is 
NOT  allowed). 

9.7. 6. 2  Errors 

All  functions  in  the  below  specification  may  optionally  return  an  <ihal:errorList>  element 
instead  of  the  defined  response.  The  error  list  is  intended  to  provide  the  user  with  a  description 
of  problems  encountered  if  the  requested  function  could  not  be  performed. 

9.7. 6. 3  APILunctions 

The  following  sections  describe  the  functions  that  must  be  included  as  part  of  any  IHAL 
API  implementation. 

9.7. 6.3.1  Retrieve  a  Vendor’s  Pool 

This  method  is  used  by  a  client  to  retrieve  some  part  of  a  vendor’s  pool  description. 

There  are  multiple  URLs  for  this  function  to  retrieve  different  parts  of  the  pool,  as  shown  in 
Table  9-13. 


Table  9-13.  Retrieve  a  Vendor’s  Pool 

URL 

<Vendor  API  Location>/pool/units  to  retrieve  the  units  pool 

<Vendor  API  Location>/pool/instrument  to  retrieve  the  instrument 
pool 

<Vendor  API  Location>/pool/measurement  to  retrieve  the  global 
measurement  list 

<Vendor  API  Location>/pool/measurement/<deviceID>  to  retrieve  the 
list  of  measurements  available  to  a  particular  device  (e.g.,  a  data 
encoder) 

<Vendor  API  Location>/pool/dataStream  to  retrieve  the  global  list  of 
data  streams  (e.g.,  buses) 

<Vendor  API  Location>/pool/dataStream/<deviceID>  to  retrieve  the 
global  list  of  data  streams  (e.g.,  buses)  available  to  a  particular  device 

HTTP  Verb 

GET 

Function  Input 

None 

Return  Value 

Complete  IHAL  <instrumentPool>,  <unitsPool>,  <measurementPool>, 
or  <dataStreamPool>  element. 

9.7. 6. 3. 2  Retrieve  the  List  of  Available  Configurations 

This  function  queries  the  web  service  for  a  list  of  existing  instrumentation  configurations 
and  is  described  in  Table  9-14. 
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Table  9-14.  Retrieve  the  List  of  Available  Configurations 

URL 

<vendor  API  Location>/configurations/ 

HTTP  Verb 

GET 

Function 

Input 

None 

Return  Value 

A  partial  <ihal>  specification  containing  0  or  more  EMPTY 
<configuration>  elements,  each  with  only  the  basic  required  information. 

No  pools  should  be  returned. 

9.7.63.3  Retrieve  a  Specific  Configuration 

This  function  uses  the  ID  of  a  configuration  returned  from  the  previous  function  call  to 
request  the  complete  description  of  that  configuration.  It  is  illustrated  in  Table  9-15. 


Table  9-15.  Retrieve  a  Specific  Configuration 

URL 

<vendor  API  Location>/configurations/<configurationID>. 
<configurationID>  contains  a  unique  identifier  returned  as  the  “id” 
attribute  from  a  call  to  “Retrieve  a  list  of  Configurations” 

HTTP  Verb 

GET 

Function  Input 

None 

Return  Value 

A  complete  IHAE  <configuration>  element 

9.7. 6. 3. 4  Change  the  Value  of  a  Configurable  Attribute 

This  function  is  used  to  change  the  values  of  settings  on  a  particular  device,  as  shown  in 
Table  9-16.  The  desired  setting  changes  are  passed  via  IHAL,  and  a  description  of  everything 
that  has  changed  as  a  result  of  these  setting  changes  is  returned  as  an  IHAL  description. 


Table  9-16.  Change  the  Value  of  a  Configurable  Attribute 

URL 

<vendor  API  Location>/configurations/<configurationID>/ 
<configurationID>  contains  a  unique  identifier  returned  as  the  “id” 
attribute  from  a  call  to  “Retrieve  a  list  of  Configurations” 

HTTP  Verb 

PUT 

Function  Input 

A  partial  <configuration>  element.  This  element  contains  only  the 
settings  that  the  user  wishes  to  modify. 

Return  Value 

The  impact:  A  partial  IHAL  <configuration>  element  containing  only 
the  new  settings  for  everything  that  has  changed: 

•  The  new  values  for  the  settings  the  user  requested  (may  or  may  not 
match  the  original  request); 

•  Any  additional  settings  that  changed  as  a  result; 

•  Any  attribute  “restrictions”  that  changed  as  a  result. 

9. 7. 6. 3. 5  Create  a  New  Configuration 

This  function  is  used  to  create  a  new  configuration  in  the  vendor’s  system.  It  is  described 
in  Table  9-17.  A  partial  or  complete  IHAL  “configuration”  element  is  passed  as  input,  and  then 
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the  vendor  responds  with  a  validated  “configuration”  element  that  matches  (as  closely  as 
possible)  the  input.  The  vendor  may  change  use-level  IDs. 


Table  9-17.  Create  a  New  Configuration 

URL 

<vendor  API  Eocation>/configurations/ 

HTTP  Verb 

POST 

Function  Input 

A  partial  or  complete  <configuration>  element. 

Return  Value 

A  validated  <configuration>  description  that  matches  (as  closely  as 
possible)  the  input  <configuration>.  Use-level  ID  values  may  change. 

9.7.63.6  Add  a  Device  to  a  Configuration 

This  function  is  used  to  add  a  device  from  the  pool  to  an  existing  configuration  in  the 
vendor’s  system.  The  function  is  depicted  in  Table  9-18.  A  partial  or  complete  IHAL 
“instrumentUse”  element  is  passed  as  input,  and  then  the  vendor  responds  with  a  valid 
“configuration”  element  that  includes  the  new  device.  The  vendor  may  change  use-level  IDs. 


Table  9-18.  Add  a  Device  to  a  Configuration 

URL 

<vendor  API  Location>/configurations/<configurationID>/devices 

HTTP  Verb 

POST 

Function  Input 

A  partial  or  complete  <instrumentUse>  element. 

Return  Value 

A  valid  <configuration>  description  that  includes  the  new  device. 
Use-level  ID  values  may  change. 

9. 7. 6. 3. 7  Remove  a  Device  from  a  Configuration 

This  function  is  used  to  remove  an  instrumentUse  from  an  existing  configuration  in  the 
vendor’s  system.  It  is  illustrated  in  Table  9-19.  The  ID  of  the  instrumentUse  element  is  included 
in  the  URL,  and  the  HTTP  “DELETE”  verb  tells  the  system  to  remove  that  device.  The  vendor 
must  respond  with  a  valid  configuration  description,  with  the  device  removed. 


Table  9-19.  Remove  a  Device  from  a  Configuration 

URL 

<vendor  API  Location>/ 

configurations/<configurationID>/devices/<instrumentUseID> 

HTTP  Verb 

DELETE 

Function  Input 

None 

Return  Value 

A  valid  <configuration>  description  with  the  device  removed 

9. 7. 6. 3. 8  “Program  ”  the  Hardware 

This  function  is  used  to  tell  the  vendor’s  configuration  engine  to  load  a  specific 
configuration  onto  the  affected  hardware.  It  is  illustrated  in  Table  9-20.  The  vendor  responds 
with  a  <configuration>  description  that  includes  updated  values  for  the  programming  status. 


Table  9-20.  “Program”  the  Hardware 

URL 

<vendor  API  Location>/ 

configurations/<configurationID>/programRequest 
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HTTP  Verb 

POST 

Function  Input 

None 

Return  Value 

A  partial  <eonfiguration>  deseription  with  the  eurrent  programming 
status  of  affeeted  deviees  updated. 

9.7.63.9  Add  a  New  format  to  a  Data  Encoder 

This  function  is  used  to  add  a  new  data  format  to  a  data  eneoder.  This  ean  be  either  a 
PCM  (SST)  format  or  a  non-TmNS  network  format.  The  elient  sends  a  partial  or  eomplete 
description  of  the  format,  and  the  vendor’s  serviee  responds  with  an  updated  <configuration> 
element  containing  ONLY  items  that  have  changed  (ineluding  the  addition  of  the  new  format). 
The  funetion  is  shown  in  Table  9-21. 


Table  9-21.  Add  a  New  Format  to  a  Data  Encoder 

URL 

<vendor  API  Loeation>/ 

configurations/<configurationID>/<instrumentUseID>/formats 

HTTP  Verb 

POST 

Function  Input 

A  eomplete  or  partial  format  “use”  deseription  (i.e.,  sstFormatUse  or 
xidMLNetworkFormatUse) 

Return  Value 

An  updated  <eonfiguration>  element  eontaining  the  new  format  as 
well  as  any  settings  in  the  eonfiguration  that  have  ehanged  as  a  result. 

9. 7.6.3.10  Add  a  Measurement  to  an  Existing  Eormat 

This  function  is  used  to  add  a  new  measurement  to  an  existing  data  format.  The  function 
is  illustrated  in  Table  9-22.  The  input  uses  either  a  XidML  <Mapping>  element  or  a  TMATS 
<Measurement>  element  to  deseribe  the  measurement  and  where  it  should  be  placed  in  the 
format.  The  vendor’s  service  responds  with  a  <configuration>  element  that  eontains  a  complete 
description  of  the  affeeted  format  as  well  as  any  settings  ehanges  that  have  oeeurred  as  a  result. 


Table  9-22.  Add  a  Measurement  to  an  Existing  Format 

URL 

<vendor  API  Location>/ 

eonfigurations/<configurationID>/<formatUseID>/measurements 

HTTP  Verb 

POST 

Function 

Input 

A  deseription  of  the  measurement  and  its  loeation  in  the  format.  This  will  be 
either  a  XidML  <Mapping>  element  or  a  TMATS-XML  <Measurement>  element. 

Return  Value 

An  updated  <configuration>  element  containing  the  modified  format  as  well  as  any 
settings  in  the  eonfiguration  that  have  ehanged  as  a  result. 

9.7.6.3.11  Remove  a  Measurement  from  a  Eormat 

This  function  is  used  to  remove  a  measurement  from  an  existing  data  format.  The 
funetion  is  illustrated  in  Table  9-23.  The  elient  speeifies  the  ID  of  the  measurement  in  the  URL. 
The  vendor’s  serviee  must  remove  ALL  instanees  of  this  measurement  from  the  specified  format. 
The  serviee  must  then  respond  with  a  <configuration>  element  that  contains  a  complete 
description  of  the  affected  format  as  well  as  any  settings  changes  that  have  oeeurred  as  a  result. 
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Table  9-23.  Remove  a  Measurement  From  a  Format 

URL 

<vendor  API  Location>/ 

configurations/<configurationID>/<fomiatUseID>/<measurementID> 

HTTP  Verb 

DELETE 

Function  Input 

None 

Return  Value 

An  updated  <configuration>  element  containing  the  modified  format  as 
well  as  any  settings  in  the  configuration  that  have  changed  as  a  result. 
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APPENDIX  9-A 

Application  of  the  Telemetry  Attributes  Transfer  Standard 

Elements  of  the  telemetry  attributes  transfer  process  allow  for  the  interchange  of 
telemetry  attributes  between  vehicle  instrumentation  organizations  (the  source)  and  the  telemetry 
ground  stations  (the  destination).  Interchange  may  also  take  place  between  ranges.  The 
following  are  typical  elements  of  this  process: 

a.  Data  entry  system 

b.  Source  database 

c.  Export  program 

d.  Interchange  medium  [this  standard] 

e.  Import  program 

f.  Destination  database 

g.  Telemetry  setup  system 

h.  Telemetry  processing  equipment. 

Eigure  A-1  depicts  these  elements,  which  are  defined  after  the  figure. 
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Source  Organization  A  Destination  Organization  X 


Source  Organization  B  Destination  Organization  Y 

Figure  A-1.  Typical  Elements  of  the  Telemetry  Attributes  Transfer  Process 

A.l.  Data  Entry  System 

The  data  entry  system  is  the  source  organization's  human  interface  where  telemetry 
attributes  are  entered  into  a  computer-based  system  (not  affected  by  this  standard). 
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A.2.  Source  Database 

The  source  database  is  where  telemetry  attributes  are  maintained  in  a  form  appropriate  to 
the  local  organization’s  needs  (not  affected  by  this  standard). 

A.3.  Export  Program 

The  export  program  converts  the  telemetry  attributes  from  the  source  database  format  to 
the  format  defined  by  this  standard  and  stores  them  on  the  interchange  medium. 

A.4.  Interchange  Medium 

The  interchange  medium  contains  the  telemetry  attributes  being  transferred  from  the 
source  organization  to  the  destination  organization.  Format  and  contents  are  defined  by  this 
standard. 

A.5.  Import  Program 

The  import  program  reads  the  standardized  interchange  medium  and  converts  the 
attributes  to  the  destination  database  format  in  accordance  with  local  needs,  system 
characteristics,  and  limitations. 

A.6.  Destination  Database 

The  destination  database  is  where  telemetry  attributes  are  maintained  in  a  form  suitable  to 
the  local  ground  station’s  needs  (not  affected  by  this  standard). 

A.7.  Telemetry  Setup  System 

The  telemetry  setup  system  accesses  the  destination  database  to  load  the  telemetry 
processing  equipment  (not  affected  by  this  standard). 

A.8.  Telemetry  Processing  Equipment 

The  telemetry  processing  equipment  is  where  the  attributes  will  ultimately  be  used  to 
properly  handle  the  data  being  transmitted  (not  affected  by  this  standard). 

The  interchange  medium  is  intended  as  a  standard  means  of  information  exchange.  The 
source  and  destination  organizations  are  not  constrained  by  this  standard  as  to  how  the  attributes 
are  stored,  viewed,  used,  or  maintained. 

To  use  the  attribute  transfer  standard,  import  and  export  software  must  be  developed. 
Once  in  place,  these  programs  should  eliminate  the  need  for  test  item  or  project-specific  software 
at  either  the  supplying  (source)  organizations  or  the  processing  (destination)  organizations. 
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APPENDIX  9-B 

Telemetry  Attributes  Transfer  Standard  Cover  Sheet 

Each  attribute  transfer  file  (disk  or  tape)  should  be  accompanied  by  a  cover  sheet 
describing  the  originating  agency’s  computer  system  used  to  construct  the  attribute  file.  The 
recommended  format  for  this  cover  sheet  is  given  below  as  Figure  B-1. 

Teleinetiy  Attiibutes  Triinsfer  Standard 

Date:  MM\DD\YY 
From:  Name 

Address 

Telephone 

To;  Name 

Address 
Telephone 

Originating  computer  system: 

Computer  make  and  model: 

Medium  characteristics: 

Description: 

Comments: 

Figure  B- 1 .  Sample  Cover  Sheet  for  Attribute  Transfer  Files 
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APPENDIX  9-C 

Telemetry  Attributes  Transfer  Standard  Format  Example 

C.l.  Introduction 

The  following  example  is  for  illustrative  purposes  and  is  by  no  means  a  eomplete 
attributes  file;  it  is  representative  of  the  types  of  information  likely  to  be  transferred.  Many 
attributes  are  purposely  omitted  to  simplify  the  example.  In  some  of  the  groups,  only  those 
entries  necessary  to  link  to  other  groups  are  provided.  Attributes  that  link  the  various  groups 
together  are  indicated  in  boldface. 

C.l.  Overview  of  Example 

Selected  attributes  are  described  in  text  form  as  an  aid  to  following  the  example.  All  text 
that  describes  the  example  is  printed  in  italics.  All  text  that  is  part  of  the  example  file  is  printed 
in  plain  text. 

The  example  file  being  transferred  consists  of  the  attributes  of  a  single  RF  data  source 
and  a  stored  data  source  containing  two  channels  of  data.  The  RF  data  source  is  a  PCM  signal, 
which  contains  an  embedded  asynchronous  wave  train.  The  two  recorded  channels  of  data  are 
PCM  signals:  one  is  an  aircraft  telemetry  stream,  and  the  other  is  a  radar  data  telemetry  stream. 
Figure  C-1  shows  the  example  file  in  terms  of  the  attribute  groups  and  their  interrelationships. 
Refer  to  the  attribute  tables  while  reviewing  the  example. 
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Figure  C- 1 .  Group  Linkages 


General  Information  Group  (G) 

Program  name,  test  name,  origination  date,  revision  number:  0,  test  number:  13. 

G\PN:  TMATS  example;  G\TA:  Wright  Flyer;  G\OD:  07-12-1903;  G\RN:0;  G\TN:13; 
G\POCl-l:  Wilbur;  G\POC2-l:  Bikes, LTD;  G\POC3-l:  Dayton;  G\POC4-l:  555-1212; 
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Live  data  source. 

G\DSI-1:PCM  w/embedded;  G\DST-1:RF; 

Data  storage  source. 

G\DSI-2:Two  PCM  links  -  TM  &  TSPI;  G\DST  2:STO; 

G\COM:  I  hope  this  flies.;  G\POCl-2:  Orville; 

G\POC2-2:Bikes,LTD;  G\POC3-2:  Dayton;  G\POC4-2:  555-1212; 

Transmission  Attributes  Group  (T-1) 

Frequency:  1489.5,  RF  bandwidth:  100,  data  bandwidth:  100;  not  encrypted,  modulation 
type:  FM,  total  carrier  modulation:  500,  no  subcarriers,  transmit  polarization:  linear. 

T-1\ID:PCM  w/embedded;  T-1\RF1: 1489.5;  T-1\RF2:100;  T-1\RF3:100; 

T-1\RF4:FM;  T-1\RF5:500;  T-l\SCO\N:NO;  T-1\AN2:LIN; 

T-l\AP\POCl:  Pat  Tern;  T-l\AP\POC2:Transmissions,Inc.; 

T-l\AP\POC3:Amityville,NY;  T-l\AP\POC4:800-555-1212; 

Recorder-Reproducer  Attributes  Group  (R-1) 

R-l\ID:Two  PCM  links  -  TM  &  TSPI; 

R-l\Rl:Recorded  Data;  R-1\TC1:MD; 

Two  channels  of  data,  manufacturer:  ZZ;  model:  13,  original:  yes. 

R-1\RI1:ZZ;  R-1\RI2:13;R-1\N:2;  R-1\RI3:Y; 

R-1\RI4:07-12-201 1-07-55-59;  R-l\POCl:Mr.  Tenn;  R-l\POC2:Data  Creations; 

R- 1  \POC  3 :  Any  where, T  town  ;R-l\POC4:555-1212; 

Channel  ID  2  contains  aircraft  telemetry  PCM  (w/subframe  fragmented) 

R-1\TK1-1:2; 

R-1\DST1:PCM  w/subframe  fragmented; 

R-  1\CDT- 1  :PCMIN;  R-1\CDLN-1:PCM1; 

Channel  ID  4  contains  Space  Position  Information  via  PCM  link 

R-l\TKl-2:4;  R-l\DST2:Space  Position  Information; 

R-1\CDT-2:PCMIN;  R-1\CDLN-2:SPI; 

Multiplex/Modulation  Group  (M-1) 

Baseband  type:  PCM,  modulation  sense:  POS,  baseband  data:  PCM,  low  pass  filter  type: 
constant  amplitude 

M-1\ID:PCM  w/embedded;  M-1\BB1:PCM;  M-l\BB2:POS;  M-1\BSG1:PCM; 

M-1\BSF2:CA; 

M-1\BB\DLN:PCM  w/async; 


PCM  Format  Attributes  Groups  (P) 
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P-1  is  a  live  PCM  signal  and  contains  the  asynchronous  wave  train  (see  Table  C-1). 
P-2  is  a  recorded  signal  (see  Table  C-2). 

P-3  is  the  asynchronous  wave  train  (see  Table  C-3). 

P-4  is  a  recorded  signal. 

Table  C-1.  PCM  Format  for  PCM  w/ASYNC 


Sync  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  « « «  39  40  41  42 


1 

2 

3 

4 

5 

6 

7 

8 

• 

• 

• 

16 

20 

bits 

ID 

C 

o 

u 

n 

t 

e 

r 

Embedded 

Format 

(Words 

6-10) 

8 

B 

i 

t 

s 

12 

B 

i 

t 

s 

a 

a 

a 

a 

a 

a 

a 

a 

• 

• 

• 

a 

b 

Major  frame  characteristics: 

One  major  frame  =16  minor  frames 

Word  lengths  =10  bits  (default  value)  except  Word  10  has  8  bits  and  Word  1 1 
has  12  bits 

a  =  measurement  E1250T  in  word  position  39 
b  =  measurement  W862P  in  word  position  42,  frame  position  8. 

PCM  Format  Group  =  P- 1 

PCM  Measurement  Description  Group  =  D-2 

Data  Link  Name  =  PCM  w/async 
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Table  C-2.  PCM  Format  for  PCMl 


Sync  1  2  3  •••  12  13  14  113  114  •••  120  121  122  •••  276 


1 

2 

3 

4 

5 

32 

37 

64 

30 

bits 

ID 

C 

o 

u 

n 

t 

e 

r 

M 

L 

6 

Bits 

4 

Bits 

M 

L 

Major  frame  characteristics: 

One  major  frame  =  64  minor  frames 
ID  counter  counts  0-63 

Word  lengths  =  10  (default  value)  except  Word  121  has  6  bits  and  Word  122 
has  4  bits 

Measurement  82AJ01  is  16  bits,  which  is  fragmented  with  the  10  msbs  indicated  as  M 
and  the  6  Isbs  as  L. 

Measurement  82AJ01  occurs  twice  in  the  major  frame. 

The  first  location  is  in  word  positions  113  and  121,  frame  position  5. 

The  second  location  is  in  word  positions  113  and  121,  frame  position  37. 

PCM  Format  Group  =  P-2 

PCM  Measurement  Description  Group  =  D-3 

Data  Link  Name  =  PCMl 
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Table  C-3.  PCM  Format  for  ASYNC 


Sync  1  2  3  •••  11  14  20  «««  29  33  39  45  46  47  48  49 


0 

16 

B 

i 

t 

s 

ID 

C 

o 

u 

n 

t 

e 

r 

a 

1 

B 

a 

B 

c 

B 

a 

B 

a 

B 

a 

B 

1 

B 

1 

1 

a 

2 

a 

1 

B 

a 

B 

B 

a 

B 

a 

B 

a 

B 

c 

B 

1 

1 

a 

■ 

3 

a 

1 

B 

a 

B 

B 

a 

B 

a 

B 

a 

B 

1 

B 

B 

1 

a 

Major  frame  characteristics: 

One  major  frame  =  3  minor  frames 
Word  lengths  =16  bits  (default  value) 


a  =  measurement  J971U,  supercommutated  in  word  positions  2,  1 1,  20,  29,  33,  and  47 
b  =  measurement  J951V  in  word  position  3,  frame  position  1 

c  =  measurement  J896D  in  two  locations:  word  position  14,  frame  position  1  and  word 
position  39,  frame  position  2 

d  =  measurement  J966X  in  word  position  45,  frame  position  3 

PCM  Format  Group  =  P-3 

PCM  Measurement  Description  Group  =  D- 1 

Data  Link  Name  =  ASYNC 


(Start  of  P-1) 

Live  PCM  signal  (host  wave  train):  Class  I 

P-1\DLN:PCM  w/async;  P-1\D1:NRZ-L;  P-1\D2:44000;  P-1\D3:U; 

P-1\D4:N;  P-1\D6:N;  P-1\D7:N;  P-l\TF:ONE; 

10  bits  default  word  length,  16  minor  frames/major  frame,  43  words/frame 

P-1\F1:10;  P-1\F2:M;  P-l\F3:NO;  P-1\MF\N:16;  P-1\MF1:43; 

P-1\MF2:440;  P-1\MF3:FPT;  P-1\MF4:20; 

P-1\MF5:  01111010011010110001;  P-1\SYNC1:1;  P-1\SYNC2:0; 
P-1\SYNC3:1;P-1\SYNC4:0; 

Word  position  #10,  8  bits.  Word  position  #11,  12  bits 
P-1\MFW1-1:10;  P-1\MFW2-1:8;  P-1\MFW1-2:11;  P-1\MFW2-2:12; 

One  subframe  ID  counter  in  word  position  1 
P-1\ISF\N:1;  P-1\ISF1-1:1;  P-1\ISF2-1:ID;  P-1\IDC1-1:1; 
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msb  starting  bit  location:  7,  ID  counter  length:  4 

P-1\IDC3-1:7;  P-1\IDC4-1:4;  P-1\IDC5-1:M; 

P-1\IDC6-1:0;  P-1\IDC7-1:1;  P-1\IDC8-1:15;  P-1\IDC9-1:16; 

P-1\IDC10-1:INC; 

Asynchronous  embedded  wave  train  information 

Data  Link  Name  (to  be  referenced  in  the  format  definition  of  the  asynchronous  wave 
train)  is  ASYNC. 

Five  contiguous  minor  frame  word  positions  starting  at  location  6. 

P-1\AEF\N:1;  P-1\AEF\DLN-1: ASYNC;  P-1\AEF1-1:5;  P-1\AEF2-1:CW; 
P-1\AEF3-1-1:6; 


(End  of  P  -1) 


(Start  of  P-2) 

Recorded  PCM  signal  format  attributes. 

Data  Link  Name  is  PCMl,  Data  Format  is  NRZ-L,  Bit  rate  is  2  Mbit/sec,  Unencrypted, 
Normal  polarity,  class  I,  Common  word  length  is  10,  msb  first.  No  parity,  64  minor 
frames  per  major  frame,  277  words  per  minor  frame.  Sync  pattern  length  is  30.  Word 
position  121  is  6  bits.  Word  position  122  is  4  bits. 

P-2\DLN:PCM1;P-2\D1:NRZ-E;  P-2\D2:2000000;  P-2\D3:U;  P-2\D4:N; 

P-2\TF:ONE;  P-2\F1:10;  P-2\F2:M;  P-2\F3:NO;  P-2\MF\N:64; 

P-2\MF1:277;  P-2\MF4:30;  P-2\MF5:101110000001100111110101101011;  P-2\SYNC1:1; 
P-2\MFW1- 1:121;  P-2\MFW2-1:6;  P-2\MFWl-2:122;P-2\MFW2-2:4; 

One  subframe  ID  counter  named  1.  Sync  type  is  ID  counter.  ID  counter  location  is  13. 
ID  counter  msb  location  is  5.  ID  counter  length  is  6.  ID  counter  transfer  order  is  msb 
first.  ID  counter  initial  value  is  0.  ID  counter  initial  frame  is  1.  ID  counter  end  value  is 
63.  ID  counter  end  frame  is  64.  ID  counter  is  increasing. 

P-2\ISF\N:1;  P-2\ISF1-1:1;  P-2\ISF2-1:ID;  P-2\IDC1-1:13; 

P-2\IDC3-1:5;  P-2\IDC4-1:6;  P-2\1DC5-1:M; 

P-2\IDC6-1:0;  P-2\IDC7-1:1;  P-2\1DC8-1:63;  P-2\IDC9-1:64; 

P-2\IDC10-1:INC; 


(End  of  P -2) 


(Start  of  P-3) 

Asynchronous  wave  train  PCM  format  attributes. 

Data  Link  Name:  ASYNC 

Class  1,  Common  word  length:  16,  Isb  transfer  order,  no  parity,  3  minor  frames  per 
major  frame,  50  w  or ds/minor  frame,  800  bits  per  minor  frame,  fixed  pattern 
synchronization,  16  bit  sync  pattern. 
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P-3\DLN:ASYNC;  P-3\TF:ONE;  P-3\F1:16;  P-3\F2:L;  P-3\F3:NO; 
P-3\MF\N:3;  P-3\MF1:50;  P-3\MF2:800;  P-3\MF3:FPT;  P-3\MF4:16; 
P-3\MF5:  1111100110110001;  P-3\SYNC1:1; 

ID  counter  in  word  position  1. 

P-3\ISF\N:1;  P-3\ISF1-1:2;  P-3\ISF2-1:ID;  P-3\IDC1-1:1; 
P-3\IDC3-1:15;  P-3\IDC4-1:2;  P-3\IDC5-1:F; 

P-3\IDC6-1:0;  P-3\IDC7-1:1;  P-3\IDC8-1:2;  P-3\IDC9-1:3; 
P-3\IDC10-1:INC; 


(End  of  P -3) 


P-4\DLN:SPI; 


(Start  of  P-4) 


(End  of  P -4) 


PCM  Measurement  Description  (D) 

D-1  contains  the  measurements  that  make  up  the  asynchronous  wave  train, 

D-2  contains  the  measurements  that  make  up  the  live  PCM  signal  ( that  hosts  the 
asynchronous  wave  train ), 

D-3  contains  the  measurements  that  make  up  one  of  the  recorded  PCM  signals,  and 
D-4  contains  the  measurements  that  make  up  the  other  recorded  PCM  signal. 


(Start  of  D-1) 

Asynchronous  Wave  Train:  One  measurement  list,  4  measurements 
D-1\DLN:ASYNC;  D-1\MF\N:1;  D-1\MFN-1:JUST  ONE;  D-1\MN\N-1:4; 

Measurement  Name:  J896D,  Isb  first. 

2  locations:  word  14,  frame  1  and  word  39,  frame  2. 

D-1\MN-1-1:J896D;  D-1\MN3-1-1:F;  D-1\FT-1-1:  WDFR; 

D-1\MMF\N-1-1:2:  D-1\MNF\N-1-1-1:1:  D-1\WP-1-1-1-1:14;  D-1\WI-1-1-1-1:0; 
D-1\FP-1-1-1-1:1;  D-1\FI-1-1-1-1:0;  D-1\WFM-1-1-1-1:FW;  D-1\MNF\N-1-1-2:1: 
D-l\WP-l-l-2-l:39;  D-l\WI-l-l-2-l:0;  D-l\FP-l-l-2-l:2;  D-l\FI-l-l-2-l:0; 
D-l\WFM-l-l-2-l:FW; 

Measurement  Name:  J951V,  Isb  first,  default  parity,  word  3,  frame  1. 

D-1\MN-1-2:J951V;  D-1\MN1-1-2:DE;  D-1\MN2-1-2:D;  D-1\MN3-1-2:F; 
D-l\FT-l-2:  WDFR;  D-1\MMF\N- 1-2:1:  D-1\MNF\N-1 -2-1:1:  D-l\WP-l-2-l-l:3; 
D-l\WI-l-2-l-l:0;  D-l\FP-l-2-l-l:l;  D-l\FI-l-2-l-l:0; 

D-  1\WFM- 1-2-1-1:1111111 100000000; 
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Measurement  Name:  J971U,  Isb  first, 

supercommutated  at  6  word  positions:  2,  11,  20,  29,  33,  and  47. 

D-1\MN-1-3:J971U;  D-1\MN1-1-3:DE;  D-1\MN2-1-3:D;  D-1\MN3-1-3:L; 
D-l\LT-l-3:  WDFR;  D-l\MML\N-l-3:6: 

D-l\MNF\N-l-3-l:l:  D-l\WP-l-3-l-l:2;  D-l\WI-l-3-l-l:0;  D-l\FP-l-3-l-l:l; 
D-l\FI-l-3-l-l:l;  D-1\WFM-1 -3-1-1  :FW; 

D-1\MNF\N-1 -3-2:1:  D-1\WP- 1-3-2-1:11;  D-l\WI-l-3-2-l:0;  D-l\FP-l-3-2-l:l; 
D-  1\FI- 1  -3-2- 1 : 1 ;  D-  1\WFM- 1  -3-2- 1  :FW; 

D-l\MNF\N-l-3-3:l:  D-l\WP-l-3-3-l:20;  D-l\WI-l-3-3-l:0;  D-l\FP-l-3-3-l:l; 
D-l\FI-l-3-3-l:l;  D-l\WFM-l-3-3-l:FW; 

D-1\MNF\N- 1-3-4: 1:  D-l\WP-l-3-4-l:29;  D-l\WI-l-3-4-l:0;  D-l\FP-l-3-4-l:l; 
D-  1\FI- 1  -3-4- 1 : 1 ;  D-  1\WFM- 1  -3-4- 1  :FW; 

D-1\MNF\N-1 -3-5:1:  D-l\WP-l-3-5-l:33;  D-l\WI-l-3-5-l:0;  D-l\FP-l-3-5-l:l; 
D-l\FI-l-3-5-l:l;D-l\WFM-l-3-5-l:FW; 

D-l\MNF\N-l-3-6:l:  D-l\WP-l-3-6-l:47;  D-l\WI-l-3-6-l:0;  D-l\FP-l-3-6-l:l; 
D-l\FI-l-3-6-l:l;D-l\WFM-l-3-6-l:FW; 

Measurement  Name:  J966X,  Isb  first,  word  45,  frame  3. 

D-1\MN-1-4:J966X;  D-1\MN1-1-4:DE;  D-1\MN2-1-4:D; 

D-1\MN3-1-4:F;  D-1\FT-1-4:WDFR;  D-1\MMF\N-1-4:1:  D-1\MNF\N-1 -4-1:1: 
D-l\WP-l-4-l-l:45;  D-1\WI-1 -4-1-1 :0;  D-l\FP-l-4-l-l:3;  D-l\FI-l-4-l-l:0; 
D-l\WFM-l-4-l-l:FW; 

(End  ofD-1 ) 


(Start  ofD-2) 

Live  PCM  signal:  single  measurement  list,  2  measurements. 

D-2\DLN:PCM  w/async;  D-2\MF\N:1;  D-2\MFN-1:JUST  ONE;  D-2\MN\N-1:2; 

Measurement  name:  E1250T,  unclassified,  unsigned,  msb  first,  word  39. 

D-2\MN-1-1:E1250T;  D-2\MN1-1-1:DE;  D-2\MN2-1-1:D; 

D-2\MN3-1-1:M;  D-2\ET-1-1:WDFR; 

D-2\MME\N- 1-1:1:  D-2\MNF\N-1-1-1:1:  D-2\WP-1-1-1-1:39;  D-2\WI- 1-1- 1-1:0; 
D-2\FP-1-1-1-1:1;  D-2\FI-1-1-1-1:1;  D-2\WFM- 1-1-1- FEW; 

Measurement  name:  W862P,  unclassified,  msb  first,  word  42,  frame  8,  full  word. 

D-2\MN-1-2:W862P;  D-2\MN1-1-2:DE;  D-2\MN2-1-2:D;  D-2\MN3-1-2:M; 
D-2\ET-l-2:  WDFR;  D-2\MME\N- 1-2:1:  D-2\MNF\N-1 -2-1:1:  D-2\WP- 1-2- 1-1:42; 
D-2\WI- 1-2- 1-1:0;  D-2\FP- 1-2- 1-1:8;  D-2\FI- 1-2- 1-1:0;  D-2\WFM- 1-2-1- FEW; 

(EndofD-2) 
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(Start  ofD-3) 

Recorded  PCM  signal:  single  measurement  list:  1  measurement. 

D-3\DLN:PCM1;  D-3\MLN-l:ONLY  ONE;  D-3\MN\N-1:1; 

Measurement  name:  82AJ01,  fragmented,  in  2  locations:  words  113  and  121,  frame  5 
and  words  113  and  121,  frame  37.  Word  113  contains  the  most  significant  fragment  and 
word  121  contains  the  least  significant  fragment. 

D-3\MN-1-1:82AJ01;  D-3\LT-1-1:  WDFR;  D-3\MML\N-1-1:1;  D-3\MNF\N-1-1-1:2; 
D-3\WP-1-1-1-1:113;  D-3\WI- 1-1- 1-1:0;  D-3\FP-1-1-1-1:5;  D-3\F1-1-1-1-1:32; 
D-3\WFM-1-1-1-1:FW; 

D-3\WP-1-1-1-2:121;  D-3\Wl-l-l-l-2:0;  D-3\FP-l-l-l-2:5;  D-3\Fl-l-l-l-2:32; 
D-3\WFM-1-1-1-2:FW; 


(EndofD-3) 


Recorded  PCM  signal 

D-4\DLN:SPI; 


(Start  of  D-4) 


(EndofD-4) 


Data  Conversion  Groups  (C) 

C-1  and  C-2  are  measurements  that  are  part  of  the  live  PCM  signal  (see  also  D-2). 

C-3,  C-4,  C-5,  and  C-6  are  from  the  asynchronous  wave  train  (see  also  D-1). 

C-7  is  from  the  recorded  PCM  signal  (see  also  D-3). 

Measurement:  E1250T,  description:  Inlet  Temp  Bellmouth,  units:  Deg  C,  binary  format: 
unsigned;  high  value:  128,  low  value:  -0.4,  conversion  type:  pair  sets,  number  of  pair 
sets:  2,  application  (polynomial):  Yes;  order  of  fit:  1,  telemetry  value  #1:  0,  engineering 
unit  value  #1:  -0.4,  telemetry  value  #2:  1023,  engineering  unit  value  #2:  128. 

C-1\DCN:E1250T;  C-l\MNl:lnlet  Temp  Bellmouth;  C-1\MN3:DEGC; 

C-1\BFM:UNS;  C-1\M0T1:128;  C-1\MOT2:-0.4;  C-1\DCT:PRS; 

C-1\PS\N:2;  C-1\PS1:Y;  C-1\PS2:1;  C-1\PS3-1:0;  C-l\PS4-l:-0.4; 

C-1\PS3-2:1023;  C-1\PS4-2:128; 

Measurement:  W862P,  description:  Euel  Pump  Inlet,  binary  format:  unsigned; 
conversion  type:  pair  sets,  number  of  pair  sets:  2,  application  (polynomial):  Yes;  order  of 
fit:  1,  telemetry  value  #1:  0,  engineering  unit  value  #1:  -0.1  telemetry  value  #2:  1023, 
engineering  unit  value  #2:  76. 7 

C-2\DCN:W862P;  C-2\MNl:Fuel  Pump  Inlet;  C-2\BFM:UNS; 

C-2\DCT:PRS;  C-2\PS\N:2;  C-2\PS1:Y;  C-2\PS2:1;  C-2\PS3-1:0; 

C-2\PS4-1:-0.1;  C-2\PS3-2:1023;  C-2\PS4-2:76.7; 
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Measurement:  J896D,  description:  Altitude,  units:  Feet,  binary  format:  two’s 
complement;  high  value:  32768,  low  value:  -32768,  conversion  type:  pair  sets;  number  of 
pair  sets:  2,  application  (polynomial):  Yes,  order  of  fit:  1,  telemetry  value  #1:  -32768, 
engineering  unit  value  #1:  -32768,  telemetry  value  #2:  32767,  engineering  unit  value  #2: 
32767 

C-3\DCN:J896D;  C-3\MN1:  Altitude;  C-3\MN3:FEET; 

C-3\BEM:TWO;  C-3\MOTl:32768;  C-3\MOT2:-32768;  C-3\DCT:PRS; 

C-3\PS\N:2;  C-3\PS1:Y;  C-3\PS2:1;  C-3\PS3-l:-32768; 

C-3\PS4-l:-32768;  C-3\PS3-2:32767;  C-3\PS4-2:32767; 

Measurement:  J951V,  description:  Throttle  Command,  units:  VDC,  high  value:  10.164, 
low  value:  -10.164,  conversion  type:  pair  sets,  number  of  pair  sets:  2, 
application(polynomial):  Yes,  order  of  fit:  1,  telemetry  value  #1:  -128,  engineering  unit 
value  #1:  -10.164,  telemetry  value  #2:  127,  engineering  unit  value  #2:  10.164,  binary 
format:  two ’s  complement 

C-4\DCN:J951V;  C-4\MN1: Throttle  Command;  C-4\MN3:VDC; 

C-4\MOT1:10.164;  C-4\MOT2:-10.164;  C-4\DCT:PRS;  C-4\PS\N:2; 

C-4\PS1:Y;  C-4\PS2:1;  C-4\PS3-1:-128;  C-4\PS4-1:-10.164; 

C-4\PS3-2:127;  C-4\PS4-2:10.164;  C-4\BPM:TWO; 

Measurement:  J971U;  description:  DISC,  conversion  type:  discrete,  binary  format: 
unsigned. 

C-5\DCN:J971U;  C-5\MN1:DISC;  C-5\DCT:DIS;  C-5\BPM:UNS; 

Measurement:  J966X;  description:  Discrete,  conversion  type:  discrete,  binary  format: 
unsigned. 

C-6\DCN:J966X;  C-6\MNl:Discrete;  C-6\DCT:DIS;  C-6\BPM:  UNS; 

Measurement:  82AJ01,  description:  LANTZ  Norm  acceleration,  units:  MTR/S/S,  High 
value:  1023.97,  Low  value:  -1023.97,  conversion  type:  Coefficients.  Order  of  curve  fit: 

1,  derived  from  pair  sets:  No,  Coefficient  (0):  0,  Coefficient(l):  0.03125,  binary  format: 
two ’s  complement 

C-7\DCN:82AJ01;  C-7\MN1:EANTZ  Norm  acceleration;  C-7\MN3:MTR/S/S; 

C-7\MOTl:  1023.97;  C-7\MOT2:- 1023.97;  C-7\DCT:COE;  C-7\CO\N:l; 

C-7\C01:N;  C-7\CO:0;  C-7\CO-1:.03125;  C-7\BPM:TWO; 

1.0  XML  Version  of  Example 

The  entire  example  is  presented  beginning  on  the  next  page  in  the  XME  version  of  the 
TMATS.  The  XME  elements  are  commented  with  TMATS  code  names  to  aid  in  associating  the 
XME  version  of  the  example  with  the  code  name  version  of  the  example  given  above. 

<?xml  version=" 1 . 0 "  encoding="ut f-8 " ?> 

<Tmat s> 

< ! --  G  Group  --> 
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<ProgramName>TMATS  example</ProgramName>< ! --PN--> 

<Test Item>Wright  Flyer</Test Itemx ! --TA--> 
<OriginationDate>l 903-07-12</OriginationDate>< ! --OD  must 
follow  XML  date  format--> 

<Revision> 

<Number>0</Number>< ! --RN--> 

</Revision> 

<TestNumber>13</TestNumber>< ! --TN--> 

<P o int Of Contact > 

<Name>Wilbur</Name>< ! --POCl--> 

<Agency>Bikes , LTD</Agency>< ! --POC2--> 
<Address>Dayton</Address>< ! --POC3--> 
<Telephone>555-1212</Telephone>< ! --POC4--> 
</PointOfContact> 

<DataSource  Name="PCM  w/embedded"  Type="RF">< ! --DSI-1 : PCM 
w/ embedded; DST-1 : RF--> 

< ! --  T  Group  --> 

<TransmissionAttributes> 

<SourceRFAttributes> 

<Frequency>1489 . 5</Frequency>< ! --RFl--> 
<RFBandwidth>l 0 0</RFBandwidth>< ! --RF2--> 
<DataBandwidth>l 0 0</DataBandwidth>< ! --RF3--> 
<Modulat ionType>FM</Modulat lonTypex ! --RF4 

enumerat ion--> 

<TotalCarrierModulat ion>5  0  0</TotalCarrierModulat ionx ! --RF5--> 

<! --Subcarriers  not  needed  SCO\N:NO--> 

< Transmit Ant enna> 

<Polarization>Linear</Polarizationx!-- 

AN2 :LIN — > 

</TransmitAntenna> 

<AntennaPatterns> 

<P o int Of Contact > 

<Name>Pat  Tern</Namex ! --AP\POCl--> 
<Agency>Transmissions , Inc . </ Agency >< ! -- 

AP\POC2 — > 

<Address>Amityville, NY</Addressx ! -- 

AP\POC3 — > 

<Telephone>80 0-555-12 12</Telephonex ! -- 

AP\POC4 — > 

</PointOfContact> 

</AntennaPatterns> 

</ SourceRFAttributes> 

</TransmissionAttributes> 
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< ! --  M  Group  --> 

< ! --Ml \ ID : PCM  w/embedded  is  implicit--> 
<MultiplexModulat ionGroup> 

<CompositeSignalStructure> 

<SignalStructureType>PCM</ Signal St ructureTypex ! --BB1 : PCM--> 

<Modulat ionSense>Posit ive</Modulat ionSensex  !  -- 

BB2 :POS — > 

</ Compos it eSignalStructure> 

<BasebandSignal> 

<SignalType>PCM</SignalTypex ! — BSGl :PCM — > 
<LowPassFilter> 

<Type>Constant  Amplitude</Typex ! --BSF2 : CA- 

> 

</LowPassFilter> 

<DataLinkName>PCM  w/ async</DataLinkNamex ! -- 

BB\DLN — > 

</BasebandSignal> 

</Mult iplexModulat ionGroup> 

<DataLink  Name="PCM  w/async"x ! --P-l\DLN--> 


> 


D6  :N — > 


<!--  P  Group  --> 

<PCMFormatAttributes> 

<InputData> 

<PCMCode>NRZ-L</PCMCodeX ! — Dl :NRZ-L — > 
<BitRate>44000</BitRatex ! — D 2:44000 — > 
<Encrypted>Unencrypted</Encryptedx ! --D3 :U- 

<Polarity>Normal</Polarityx ! --D4 :N--> 
<DataDirect ion>Normal</DataDirect ionx ! -- 

<DataRandomized>No</DataRandomizedx ! --D7 :N 


-> 

</ InputData> 

<Eormat> 

<TypeEormat>Class  l</TypeEormatx ! --TE : ONE- 

> 


El : 10 — > 


<CommonWordLength>l 0</ CommonWordLengthx ! -- 


<WordTransf erOrder>MSB 
Eirst</WordTransf erOrderX ! --E2 :M--> 

<Parity>None</Parityx ! --E3 :NO--> 
<MinorErame> 


<NumberOfMinorErames>l 6</NumberOfMinorEramesx ! --ME\N : 1 6--> 
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<WordsPerMinorFrame>43</WordsPerMinorFrame>< ! --MF1 : 43--> 


<BitsPerMinorFrame>440</BitsPerMinorFrame>< ! --MF2 : 440--> 

<SyncType>Fixed  Pattern</ SyncTypex ! - 


MF3 :FPT — > 


<!--MF4:20  is  implicit--> 


<SyncPattern>01111010011010110001</SyncPattern><!-- 

MF5 : 01111010011010110001--> 

</MinorFrame> 

</Format> 

<SyncCriteria> 

<InSync> 

<Criteria>l</Criteria><!--SYNCl:l--> 
<NumberOfFSPBit s>0</NumberOfFSPBit s>< 

SYNC2 : 0 — > 

</ InSync> 

<OutOf Sync> 

<NumberOfDisagrees>Not 

Specif ied</NumberOfDisagrees>< ! --SYNC3 : l--> 

<NumberOfFSPBit s>0</NumberOfFSPBit s>< 

SYNC4 : 0 — > 

</OutOf Sync> 

</SyncCriteria> 

<VariableWordLength> 

<Word>10</Word>< ! — MFWl-1 — > 
<Length>8</Length>< ! --MFW2-l--> 
</VariableWordLength> 

<VariableWordLength> 

<Word>ll</Word>< ! — MFWl-2 — > 
<Length>12</Length>< ! --MFW2-2--> 
</VariableWordLength> 

<Subf rameSynchronizat ion> 

<IDCounter>< ! --ISF\N : 1  is  implicit--> 
<Name>l</Name>< ! — ISFl : 1 — > 
<SyncType>ID  Counter</ SyncTypex ! -- 

ISF2 : ID — > 

<Location>l</Locationx!--IDCl:l--> 


<CounterStartingBitLocation>7</ Count er St art ingBitLocationx ! - 
IDC3 : 7 — > 


IDC4 : 4 — > 


<CounterLength>4</ CounterLengthx ! -- 


<Transf erOrder>MSB 
First</TransferOrderX ! --IDC5 :M--> 
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IDC6: 0 — > 


<InitialValue>0</InitialValue><!-- 


<Init ialSubf rameNumber>l</ Init ialSubf rameNumberX !--IDC7:l--> 

<EndValue>15</EndValue>< ! --IDC8 : 15--> 

<EndSubf rameNumber>l 6</EndSubf rameNumberX !--IDC9:16--> 

<CountDirect ion>Increasing</ CountDirect ionx !--IDC10:INC--> 

</ IDCounter> 

</ Subf rameSynchronization> 
<AsyncEmbeddedEormat> 

<!--AEE\N:l  is  implicit--> 
<DataLinkName>ASYNC</DataLinkNamex ! -- 

AEE\DLN-1 : ASYNC — > 

<Supercom>5</ Supercomx ! --AEE1-1 : 5--> 
<LocationDefinition>Contiguous 
Words</Locat ionDef init ionx ! --AEE2-1 : CW--> 

<Location>6</Locationx ! --AEE3-1-1 : 6--> 
</AsyncEmbeddedEormat> 


liJUST  ONE — > 

1 :E1250T — > 

1  :DE  —  > 


< ! --  D  Group  --> 

< ! --D-2 \DLN : PCM  w/async  is  implicit--> 
<PCMMeasurement s> 

< ! --D-2 \ML\N : 1  is  implicit--> 
<MeasurementList  Name="JUST  ONE"x! — MLN- 

<!--MN\N-l:2  is  implicit--> 
<Measurement  Name="El250T"x ! --MN-1- 

<Parity>Def ault</Parityx ! --MN1-1- 


<ParityTransferOrder>Def ault</ParityTransf erOrderX ! --MN2-1-1 :D- 
-> 

<MeasurementTransf erOrder>MSB 
Eirst</MeasurementTransf erOrderX ! --MN3-1-1 :M--> 

<Locat ionType>Word  and 
Erame</Locat ionTypex ! --LT-1-1 :WDER--> 

< ! --MML\N-1-1 : 1  is  implicit--> 
<MeasurementLocat ion> 

< ! --MNE\N-1-1-1 : 1  is  implicit--> 
<MeasurementEragment s> 

<StartWord>3 9</ StartWordx ! - 


-WP-1-1-1-1 : 39 — > 


<WordInterval>0</WordIntervalx ! --WI-1-1-1-1 : 0--> 
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<StartFrame>l</ StartFramex ! --FP-1-1-1-1 : l--> 

<FrameInterval>l</FrameInterval>< ! --FI-1-1-1-1 : l--> 

<BitMask>Full 

Word</BitMask>< ! — WFM-1-1-1-1 : FW — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 
</Measurement> 

<Measurement  Name="W862P">< ! 

2 :W862P — > 

<Parity>Def ault</Parity>< ! --MN1-1- 

2  :DE  —  > 


<ParityTransferOrder>Def ault</ParityTransf erOrderX ! --MN2-1-2 :D- 
-> 


<Measurement Trans ferOrder>MSB 
First</MeasurementTransf erOrderX ! --MN3-1-2 :M--> 

<Locat ionType>Word  and 
Frame</Locat ionTypex ! --LT-1-2 :WDFR--> 

< ! --MML\N-l-2 : 1  is  implicit--> 
<MeasurementLocat ion> 


< ! --MNF\N-l-2-l : 1  is  implicit--> 
<MeasurementFragment s> 

<StartWord>42</ StartWordx ! - 

-WP-1-2-1-1 : 42 — > 


<WordInterval>0</WordIntervalx ! --WI-1-2-1-1 : 0--> 

<StartFrame>8</ StartFramex ! --FP-1-2-1-1 : 8--> 

<FrameInterval>0</FrameIntervalx ! --FI-1-2-1-1 : 0--> 

<BitMask>Full 

Word</BitMaskX ! — WFM-1-2-1-1 :FW — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 

</Measurement> 

< /Measurement Li St > 

</PCMMeasurement s> 

</PCMFormatAttributes> 

<!--  C  Group  --> 

<DataConversionAttributes> 

<Measurement  Name="El250T"x ! — C-1\DCN:E1250T — > 
<Measurand> 

<Descript ion>Inlet  Temp 

Bellmouth</Descript ionx ! --MN1 : Inlet  Temp  Bellmouth--> 
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<EngineeringUnit s>DEGC</EngineeringUnit s>< ! --MN3 :DEGC--> 

</Measurand> 

<TelemetryValueDef init ion> 

<BinaryEormat>Un signed 
Binary</BinaryEormat>< ! --BEM: UNS--> 

</TelemetryValueDef init ion> 

<OtherInf ormat ion> 

<MeasurementValue> 

<Low>-0 . 4</Low>< ! — MOT2 : -0 . 4 — > 
<High>128 . 0</High>< ! — MOTl : 128 — > 
</MeasurementValue> 

</OtherInf ormat ion> 

<DataConversion  Type="Pair  Sets"><!-- 

DCTtPRS — > 

<PairSet s> 

<!--PS\N:2  is  implicit--> 

<Applicat ion>Polynomial  Curve 
Eit</Application>< !--PSl:Y--> 

<OrderOfEit>l</OrderOfEit>< ! --PS2 : 1- 

-> 

<Pair> 

<TmValue>0</TmValue>< ! --PS3-1 : 0- 

-> 

<EuValue>-0 . 4</EuValue>< ! — PS4- 

l:-0.4--> 

</Pair> 

<Pair> 

<TmValue>1023</TmValue>< ! --PS3- 

2 : 1023--> 

<EuValue>12 8</EuValue>< ! --PS4- 

2 : 128--> 

</Pair> 

</PairSet s> 

</DataConversion> 

</Measurement> 

<Measurement  Name="W862P">< ! --C-2\DCN :W862P--> 
<Measurand> 

<Descript ion>Euel  Pump 

Inlet</Descript ionx ! --MN1 : Inlet  Temp  Bellmouth--> 

</Measurand> 

<TelemetryValueDef init ion> 

<BinaryEormat>Un signed 
Binary</BinaryFormat>< ! --BEM: UNS--> 

</TelemetryValueDef init ion> 
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DCTiPRS — > 


<DataConversion  Type="Pair  Sets"><!-- 


<PairSet s> 

<!--PS\N:2  is  implicit--> 

<Applicat ion>Polynomial  Curve 
Fit</Application>< !--PSl:Y--> 

<OrderOfFit>l</OrderOfFit>< ! --PS2 : 1 

-> 

<Pair> 

<TmValue>0</TmValue>< ! --PS3-1 : 0 

-> 

<EuValue>-0 . l</EuValue>< ! — PS4- 

1 :-0 . l--> 

</Pair> 

<Pair> 

<TmValue>1023</TmValue>< ! --PS3- 

2 : 1023--> 

<EuValue>7  6 . 7</EuValue>< ! --PS4- 

2:76. 7--> 

</Pair> 

</PairSet s> 

</DataConversion> 

</Measurement> 

</DataConversionAttributes> 

</DataLink> 


<DataLink  Name="ASYNC">< ! — P-3\DLN: ASYNC — > 


<!--  P  Group  --> 

<PCMEormatAttributes> 

<Eormat> 

<TypeEormat>Class  l</TypeEormat>< ! --TE : ONE- 


E1 : 16  —  > 


<CommonWordLength>l 6</ CommonWordLengthx ! -- 


<WordTransf erOrder>LSB 
Eirst</WordTransf erOrderX ! --E2 : L--> 

<Parity>None</Parityx ! --E3 :NO--> 
<MinorErame> 


<NumberOfMinorErames>3</NumberOfMinorEramesx ! --ME\N : 3--> 

<WordsPerMinorErame>50</WordsPerMinorEramex ! --ME1 : 50--> 

<Bit sPerMinorErame>8 0 0</Bit sPerMinorEramex ! --ME2 : 800--> 

<SyncType>Eixed  Pattern</ SyncTypex ! -- 


ME3 :EPT — > 
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<!--MF4:16  is  implicit--> 

<SyncPattern>1111100110110001</SyncPattern><!-- 
MF5 : 1111100110110001--> 

</MinorFrame> 

</Format> 

<SyncCriteria> 

<InSync> 

<Criteria>l</Criteria><!--SYNCl:l--> 

</ InSync> 

</SyncCriteria> 

<Subf rameSynchronizat ion> 

<IDCounter>< ! --ISF\N : 1  is  implicit--> 
<Name>2</Name>< !--ISFl-l:2--> 
<SyncType>ID  Counter</ SyncTypex ! --ISF2- 

1  :  ID  —  > 

<Location>l</Location><!--IDCl-l:l--> 


<CounterStartingBitLocation>15</ Count er St art ingBitLocationx ! -- 
IDC3-1 : 15 — > 


IDC4-1 : 2 — > 


<CounterLength>2</ CounterLengthx ! -- 


<Transf erOrder>LSB 

Fir St < /Trans ferOrderX !--IDC5-l:L--> 

<Initia lvalue >0</Initia lvalue x!--IDC6- 


1 :  0--> 


<Init ialSubf rameNumber>l</ Init ialSubf rameNumberX !--IDC7-l:l--> 

<EndValue>2</EndValuex !--IDC8-l:2--> 

<EndSubframeNumber>3</EndSubf rameNumberX ! --IDC9-1 : 3--> 


<CountDirect ion>Increasing</ CountDirect ionx !--IDC10-l:INC--> 

</ IDCounter> 

</ Subf rameSynchronization> 


< ! --  D  Group  --> 

<! — D-1\DLN: ASYNC  is  implicit — > 
<PCMMeasurement s> 

< ! --D-1 \ML\N : 1  is  implicit--> 
<MeasurementList  Name="JUST  ONE"x! — MLN- 

liJUST  ONE — > 

<!--MN\N-l:4  is  implicit--> 
<Measurement  Name=" J8  9  6D"x ! --MN-1- 

1 : J896D — > 


<MeasurementTransf erOrder>LSB 
Eir St < /Measurement Trans ferOrderX ! --MN3-1-1 : L--> 
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<Locat ionType>Word  and 
Frame</Locat ionTypex ! --LT-1-1 :WDFR--> 

< ! --MML\N-1-1 : 2  is  implicit--> 
<MeasurementLocat ion> 

< ! --MNF\N-1-1-1 : 1  is  implicit--> 
<MeasurementFragment s> 

<StartWord>14</ StartWordx ! - 


-WP-1-1-1-1 : 14 — > 


<WordInterval>0</WordIntervalx ! --WI-1-1-1-1 : 0--> 

<StartFrame>l</ StartFramex ! --FP-1-1-1-1 : l--> 

<FrameInterval>0</FrameIntervalx ! --FI-1-1-1-1 : 0--> 

<BitMask>Full 

Word</BitMaskX ! — WFM-1-1-1-1 :FW — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 
<MeasurementLocat ion> 

< ! --MNF\N-l-l-2 : 1  is  implicit--> 
<MeasurementFragment s> 

<StartWord>3 9</ StartWordx ! - 

-WP-1-1-1-1 : 39 — > 

<WordInterval>0</WordIntervalx ! --WI-1-1-1-1 : 0--> 

<StartFrame>2</ StartFramex ! --FP-1-1-1-1 : 2--> 

<FrameInterval>0</FrameIntervalx ! --FI-1-1-1-1 : 0--> 

<BitMask>Full 

Word</BitMaskX ! — WFM-1-1-2-1 :FW — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 

</Measurement> 

<Measurement  Name=" J95lV"x ! --MN-1- 

2 : J951V — > 

<Parity>Def ault</Parityx ! --MN1-1- 

2  :DE  —  > 


<ParityTransferOrder>Def ault</ParityTransf erOrderX ! --MN2-1-2 :D- 
-> 

<Measurement Trans ferOrder>LSB 
Fir St < /Measurement Trans ferOrderX ! --MN3-1-2 : L--> 

<Locat ionType>Word  and 
Frame</Locat ionTypex ! --LT-1-2 :WDFR--> 

< ! --MML\N-l-2 : 1  is  implicit--> 
<MeasurementLocat ion> 
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< ! --MNF\N-l-2-l : 1  is  implicit--> 
<MeasurementFragment s> 

<StartWord>3</ StartWordx ! -- 

WP-1-2-1-1 : 3 — > 

<WordInterval>0</WordInterval>< ! --WI-1-2-1-1 : 0--> 

<StartFrame>l</ StartFramex ! --FP-1-2-1-1 : l--> 

<FrameInterval>0</FrameIntervalx ! --FI-1-2-1-1 : 0--> 

<BitMask>1111111100000000</BitMaskx ! — WFM-1-2-1- 
1 : 1111111100000000 — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 

</Measurement> 

<Measurement  Name=" J971U"x ! --MN-1- 

3: J971U — > 

<Parity>Def ault</Parityx ! --MN1-1- 

3  :DE  —  > 


<ParityTransferOrder>Def ault</ParityTransf erOrderX ! --MN2-1-3 :D- 
-> 


<MeasurementTransf erOrder>LSB 
Fir St < /Measurement Trans ferOrderX ! --MN3-1-3 : L--> 

<Locat ionType>Word  and 
Frame</Locat ionTypex ! --LT-1-3 :WDFR--> 

< ! --MML\N-l-3 : 6  is  implicit--> 
<MeasurementLocat ion> 


< ! --MNF\N-l-3-l : 1  is  implicit--> 
<MeasurementFragment s> 

<StartWord>2</ StartWordx ! -- 

WP-1-3-1-1 : 2 — > 


<WordInterval>0</WordIntervalx ! --WI-1-3-1-1 : 0--> 

<StartFrame>l</ StartFramex ! --FP-1-3-1-1 : l--> 

<FrameInterval>l</FrameIntervalx ! --FI-1-3-1-1 : l--> 

<BitMask>Full 

Word</BitMaskx ! — WFM-1-3-1-1 :FW — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 
<MeasurementLocat ion> 

< ! --MNF\N-l-3-2 : 1  is  implicit--> 
<MeasurementFragment s> 
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-WP-1-3-2-1 : 11 — > 


<StartWord>l !</ StartWordx ! - 


<WordInterval>0</WordInterval>< ! --WI-1-3-2-1 : 0--> 

<StartFrame>l</ StartFramex ! --FP-1 -3-2-1 : l--> 

<FrameInterval>l</FrameIntervalx ! --FI-1-3-2-1 : l--> 

<BitMask>Full 

Word</BitMaskx ! — WFM-1-3-2-1 :FW — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 
<MeasurementLocat ion> 

< ! --MNF\N-l-3-3 : 1  is  implicit--> 
<MeasurementFragment s> 

<StartWord>2 0</ StartWordx ! - 

-WP-1-3-3-1 : 20 — > 

<WordInterval>0</WordIntervalx ! --WI-1-3-3-1 : 0--> 

<StartFrame>l</ StartFramex ! --FP-1 -3-3-1 : l--> 

<FrameInterval>l</FrameIntervalx ! --FI-1-3-3-1 : l--> 

<BitMask>Full 

Word</BitMaskx ! — WFM-1-3-3-1 :FW — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 
<MeasurementLocat ion> 

< ! --MNF\N-l-3-4 : 1  is  implicit--> 
<MeasurementFragment s> 

<StartWord>2  9</ StartWordx ! - 

-WP-1-3-4-1 : 29 — > 


<WordInterval>0</WordIntervalx ! --WI-1-3-4-1 : 0--> 

<StartFrame>l</ StartFramex ! --FP-1 -3-4-1 : l--> 

<FrameInterval>l</FrameIntervalx ! --FI-1-3-4-1 : l--> 

<BitMask>Full 

Word</BitMaskx ! — WFM-1-3-4-1 :FW — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 
<MeasurementLocat ion> 

< ! --MNF\N-l-3-5 : 1  is  implicit--> 
<MeasurementFragment s> 

<StartWord>33</ StartWordx ! - 

-WP-1-3-5-1 : 33 — > 
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<WordInterval>0</WordInterval>< ! --WI-1-3-5-1 : 0--> 

<StartFrame>l</ StartFramex ! --FP-1 -3-5-1 : l--> 

<FrameInterval>l</FrameInterval>< ! --FI-1-3-5-1 : l--> 

<BitMask>Full 

Word</BitMask>< ! — WFM-1-3-5-1 : FW — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 
<MeasurementLocat ion> 

< ! --MNF\N-l-3-6 : 1  is  implicit--> 
<MeasurementFragment s> 

<StartWord>47</ StartWordx ! - 

-WP-1-3-6-1 : 47 — > 

<WordInterval>0</WordIntervalx ! --WI-1-3-6-1 : 0--> 

<StartFrame>l</ StartFramex ! --FP-1-3-6-1 : l--> 

<FrameInterval>l</FrameIntervalx ! --FI-1-3-6-1 : l--> 

<BitMask>Full 

Word</BitMaskx ! — WFM-1-3-6-1 :FW — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 

</Measurement> 

<Measurement  Name=" J966X"x ! --MN-1- 

4 : J966X — > 

<Parity>Def ault</Parityx ! --MN1-1- 

4  :DE  —  > 


<ParityTransferOrder>Def ault</ParityTransf erOrderX ! --MN2-1-4 :D- 
-> 


<MeasurementTransf erOrder>LSB 
Fir St < /Measurement Trans ferOrderX ! --MN3-1-4 : L--> 

<Locat ionType>Word  and 
Frame</Locat ionTypex ! --LT-1-4 :WDFR--> 

< ! --MML\N-l-4 : 1  is  implicit--> 
<MeasurementLocat ion> 

< ! --MNF\N-l-4-l : 1  is  implicit--> 
<MeasurementFragment s> 

<StartWord>45</ StartWordx ! - 


-WP-1-4-1-1 : 45 — > 


<WordInterval>0</WordIntervalx ! --WI-1-4-1-1 : 0--> 
<StartFrame>3</ StartFramex ! --FP-1-4-1-1 : 3--> 


C-23 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  9,  July  2017 


<FrameInterval>0</FrameInterval>< ! --FI-1-4-1-1 : 0--> 

<BitMask>Full 

Word</BitMask>< ! — WFM-1-4-1-1 : FW — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 
</Measurement> 

< /Measurement Li St > 

</PCMMeasurement s> 

</PCMFormatAttributes> 

<!--  C  Group  --> 

<DataConversionAttributes> 

<Measurement  Name=" J8 9  6D">< !--C-3\DCN:J89  6D--> 
<Measurand> 

<Descript ion>Terrain 

Alt itude</ Descript ionx ! --MN1 : Terrain  Alt itude--> 

<EngineeringUnit s>FEET</EngineeringUnit s>< ! --MN3 :EEET--> 

</Measurand> 

<TelemetryValueDef init ion> 

<BinaryEormat>Two ' s 

Complement</BinaryFormat>< ! --BEM : TWO--> 

</TelemetryValueDef init ion> 

<OtherInf ormat ion> 

<MeasurementValue> 

<Low>-32768 . 0</Low>< ! — MOT2 : -327 68- 

> 

<High>32768 . 0</High>< ! — MOTl : 327 68- 

> 

</MeasurementValue> 

</OtherInf ormat ion> 

<DataConversion  Type="Pair  Sets"><!-- 

DCTtPRS — > 

<PairSet s> 

<!--PS\N:2  is  implicit--> 

<Applicat ion>Polynomial  Curve 
Eit</Application>< !--PSl:Y--> 

<OrderOfEit>l</OrderOfEit>< ! --PS2 : 1 

-> 

<Pair> 

<TmValue>-32  7  68</TmValue>< ! -- 

PS3-1  :-32768  — > 

<EuValue>-32  7  68 . 0</EuValue>< ! -- 

PS4-1  :-32768  — > 

</Pair> 

<Pair> 
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2 : 32767 — > 
PS4-2 : 32767 — > 


<TmValue>32  7  67</TmValue>< ! --PS3 
<EuValue>32  7  67 . 0</EuValue>< ! -- 


</Pair> 
</PairSet s> 
</DataConversion> 
</Measurement> 


<Measurement  Name=" J951V">< ! --C-4\DCN : J95lV--> 
<Measurand> 

<Descript ion>Thrott le 

Command</Descript ionx ! --MN1 : Throttle  Command--> 


<EngineeringUnit s>VDC</EngineeringUnit s>< ! --MN3 : VDC--> 

</Measurand> 

<TelemetryValueDef init ion> 

<BinaryEormat>Two ' s 

Complement</BinaryFormat>< ! --BEM : TWO--> 

</TelemetryValueDef init ion> 

<OtherInf ormat ion> 

<MeasurementValue> 

<Low>-10 . 164</Low>< ! — MOT2 : -10 . 164- 

> 


<High>10 . 164</High>< ! — MOTl : 10 . 164- 

> 

</MeasurementValue> 

</OtherInf ormat ion> 

<DataConversion  Type="Pair  Sets"><!-- 

DCTtPRS — > 

<PairSet s> 

<!--PS\N:2  is  implicit--> 

<Applicat ion>Polynomial  Curve 
Eit</Application>< !--PSl:Y--> 

<OrderOfFit>l</OrderOfEit>< ! --PS2 : 1 

-> 

<Pair> 

<TmValue>-128</TmValue>< ! --PS3- 

1 :-128 — > 

<EuValue>-l 0 . 1 64</EuValue>< ! -- 

PS4-1 : -10 . 164 — > 

</Pair> 

<Pair> 

<TmValue>127</TmValue>< ! --PS3- 

2 : 127 — > 

<EuValue>l 0 . 1 64</EuValue>< ! -- 

PS4-2 : 10 . 164 — > 


C-25 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  9,  July  2017 


</Pair> 

</PairSet s> 

</DataConversion> 

</Measurement> 

<Measurement  Name=" J971U">< ! --C-5\DCN : J97lU--> 
<Measurand> 

<Descript ion>DISC</Descript ionx ! -- 

MNl :DISC — > 

</Measurand> 

<TelemetryValueDef init ion> 

<BinaryFormat>Un signed 
Binary</BinaryFormat>< ! --BFM: UNS--> 

</TelemetryValueDef init ion> 

<DataConversion  Type="Discrete">< ! --DCT : DIS 

-> 

< ! --what  else  goes  here?--> 
</DataConversion> 

</Measurement> 

<Measurement  Name=" J966X">< ! --C-6\DCN : J966X--> 
<Measurand> 

<Descript ion>Discrete</Descript ionx ! -- 

MNl iDiscrete — > 

</Measurand> 

<TelemetryValueDef init ion> 

<BinaryFormat>Un signed 
Binary</BinaryFormatx ! --BFM: UNS--> 

</TelemetryValueDef init ion> 

<DataConversion  Type="Discrete"x ! --DCT : DIS 

-> 

< ! --what  else  goes  here?--> 
</DataConversion> 

</Measurement> 

</DataConversionAttributes> 

</DataLink> 

</DataSource> 

<P o int Of Contact > 

<Name>Orville</Namex ! --POC1-2 :  Orville--> 

<Agency>Bikes , LTD< / Agency >< ! --POC2-2 : Bikes , LTD--> 
<Address>Dayton</Addressx ! --POC3-2 :  Dayton--> 
<Telephone>555-1212</Telephonex I--POC4-2:  555-1212--> 
</PointOfContact> 
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<DataSource  Name="Two  PCM  links  -  TM  &amp;  TSPI" 
Type="Storage">< ! — DSI-2:Two  PCM  links  -  TM  &  TSPI ; DST-2 : STO — > 

< ! --  R  Group  --> 

<RecorderReproducerAttributes> 

<ID>Two  PCM  links  -  TM  &amp;  TSPI</ID><! — R-l\ID:Two 
PCM  links  -  TM  &  TSPI — > 

<Descript ion>Recorded  Data</Descript ionx ! -- 
RIiRecorded  Data--> 

<Characterist ics> 

<Type>Magnet ic  Disk</Type>< ! --TCI :MD--> 

<NumberOf TracksOrChannels>2</NumberOf TracksOrChannelsx ! --N : 2--> 
</Characteristics> 

<RecorderReproducerInf o> 

<Manuf acturer>ZZ</Manuf acturerx ! --RII : ZZ--> 
<Model>I3</Modelx ! --RI2 : I3--> 

<OriginalRecording>Yes</OriginalRecordingx ! -- 

RI3 : Y — > 

<OriginalRecordingDateAndTime>2  0 11-0  7- 
I2T07 : 55 : 5 9</OriginalRecordingDateAndTimex !--RI4:07-I2-20II-07- 
55-59--> 

<Creat ingOr ganiz at ionPo int Of Contact > 

<Name>Mr.  Tenn</Namex ! --POCI : Mr .  Tenn--> 
<Agency>Data  Great ions</Agencyx ! --POC2 :Data 

Great ions--> 

<Address>Anywhere, Ttown</Addressx ! -- 
POC3 : Anywhere, Ttown--> 

<Telephone>555-I2 I2</Telephonex ! --POC4 : 555- 

I2I2--> 

</ Great ingOr ganiz at ionPo int Of Contact > 
</RecorderReproducerInf o> 

<Data> 

<TrackNumberOrChannelID>2</TrackNumberOrChannelIDX ! --TK1-1 : 2--> 

<DataSourceID>PCM  w/subframe 

f ragmented</DataSourceIDX ! --DSI-1 : PCM  w/subframe  f ragmented--> 

<ChannelDataType>PCM  Input</ ChannelDataTypex ! -- 

CDT-1 iPCMIN — > 

<ChannelDataLinkName>PCMl</ ChannelDataLinkNamex ! --CDLN-1 : PCM1-- 
> 

<TrackNumberOrChannelID>4</TrackNumberOrChannelIDX ! --TK1-2 : 4--> 

<DataSourceID>Space  Position 

Inf ormat ion</DataSourceIDX ! --DSI-2 : Space  Position  Inf ormat ion-- 
> 
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<ChannelDataType>PCM  Input</ ChannelDataTypex ! - 

CDT-2 iPCMIN — > 


<ChannelDataLinkName>SPI</ ChannelDataLinkNamex ! --CDLN-2 : SPI--> 
</Data> 

</RecorderReproducerAttributes> 

</DataSource> 

<DataLink  Name="PCMl"x ! — P-2\DLN:PCM1 — > 

<!--  P  Group  --> 

<PCMFormatAttributes> 

<InputData> 

<PCMCode>NRZ-L</PCMCodeX ! — Dl :NRZ-L — > 
<BitRate>2000000</BitRatex ! — D2 : 2000000 — > 
<Encrypted>Unencrypted</Encryptedx ! --D3 :U- 

> 

<Polarity>Normal</Polarityx ! --D4 :N--> 

</ InputData> 

<Eormat> 

<TypeEormat>Class  l</TypeEormatx ! --TE : ONE- 


<CommonWordLength>l 0</ CommonWordLengthx ! -- 

El :  10  —  > 

<WordTransf erOrder>MSB 
Eirst</WordTransf erOrderX ! --E2 :M--> 

<Parity>None</Parityx ! --E3 :NO--> 
<MinorErame> 


<NumberOfMinorErames>64</NumberOfMinorEramesx ! --ME\N : 64--> 

<WordsPerMinorErame>277</WordsPerMinorEramex ! --ME1 : 277--> 

<!--ME4:30  is  implicit--> 

<SyncPattern>101110000001100111110101101011</SyncPatternx ! — 
ME5 : 101110000001100111110101101011--> 

</MinorErame> 

</Eormat> 

<SyncCriteria> 

<InSync> 

<Criteria>l</Criteriax!--SYNCl:l--> 
</ InSync> 

</SyncCriteria> 

<VariableWordLength> 

<Word>121</Wordx ! — MEWl-1 : 121 — > 
<Length>6</Lengthx ! --MEW2-1 : 6--> 
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</VariableWordLength> 

<VariableWordLength> 

<Word>122</Word>< ! --MFW1-2 : 122--> 
<Length>4</Length>< ! --MFW2-2 : 4--> 
</VariableWordLength> 

<Subf rameSynchronizat ion> 

<IDCounter>< ! --ISF\N : 1  is  implicit--> 
<Name>l</Name>< ! — ISFl-1 : 1 — > 
<SyncType>ID  Counter</ SyncTypex ! --ISF2- 

1  :  ID  —  > 

<Location>13</Location><!--IDCl-l:13--> 


<CounterStartingBitLocat ion>5</ Count er St art ingBitLocationx ! -- 
IDC3-1 : 5 — > 


IDC4-1 : 6 — > 


<CounterLength>6</ CounterLengthx ! -- 


<Transf erOrder>MSB 

First</TransferOrderX ! --IDC5-1 :M--> 

<Initia lvalue >0</Initia lvalue x!--IDC6- 


1 :  0--> 


<Init ialSubf rameNumber>l</ Init ialSubf rameNumberX !--IDC7-l:l--> 

<EndValue>63</EndValuex ! --IDC8-1 : 63--> 

<EndSubframeNumber>64</EndSubf rameNumberX ! --IDC9-1 : 64--> 

<CountDirect ion>Increasing</ CountDirect ionx !--IDC10-l:INC--> 

</ IDCounter> 

</ Subf rameSynchronization> 

< ! --  D  Group  --> 

<PCMMeasurement s> 

< ! --D-3\DLN : PCMl  is  implicit--> 

<MeasurementList  Name="ONLY  ONE"x!--MLN- 

l:ONLY  ONE — > 

<!--MN\N-l:l  is  implicit--> 

<Measurement  Name="82AJ01"x ! --MN-1- 

1 : 82AJ01 — > 

<Locat ionType>Word  and 
Erame</Locat ionTypex ! --LT-1-1 :WDER--> 

<MeasurementLocat ion> 

<MeasurementEragment s> 

<StartWord>l 13</ StartWordx ! --WP-1-1-1-1 : 113--> 
<WordInterval>0</WordIntervalx ! --WI-1-1-1-1 : 0--> 
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<StartFrame>5</ StartFramex ! --FP-1-1-1-1 : 5--> 

<FrameInterval>32</FrameInterval>< ! --FI-1-1-1-1 : 32--> 

<BitMask>Full 

Word</BitMask>< ! — WFM-1-1-1-1 : FW — > 

</MeasurementFragment s> 
</MeasurementLocat ion> 
<MeasurementLocat ion> 

<MeasurementFragment s> 

<StartWord>121</ StartWordx ! --WP-1-1-1-2 : 121--> 
<WordInterval>0</WordIntervalx ! --WI-1-1-1-2 : 0--> 
<StartFrame>5</ StartFramex ! --FP-1-1-1-2 : 5--> 


<FrameInterval>32</FrameIntervalx ! --FI-1-1-1-2 : 32--> 

<BitMask>FW</BitMaskx ! -- 


WFM-1-1-1-2 :FW — > 


</MeasurementFragment s> 
</MeasurementLocat ion> 
</Measurement> 

< /Measurement Li St > 

</PCMMeasurement s> 
</PCMFormatAttributes> 


<!--  C  Group  --> 

<DataConversionAttributes> 

<Measurement  Name="82AJ01"x ! --C-7\DCN : 82AJ01--> 
<Measurand> 

<Descript ion>LANTZ  Norm 

accelerat ion</Descript ionx ! --MN1 : LANTZ  Norm  accelerat ion--> 

<EngineeringUnit s>MTR/ S/ S</EngineeringUnit sx ! --MN3 :MTR/ S/ S--> 

</Measurand> 

<TelemetryValueDef init ion> 

<BinaryEormat>Two ' s 

Complement</BinaryFormatx ! --BEM: TWO--> 

</TelemetryValueDef init ion> 

<OtherInf ormat ion> 

<MeasurementValue> 

<Low>-1023 . 97</LowX ! — MOT2 : - 

1023 . 91  — > 

<High>1023. 97</Highx!-- 

MOTl : 1023 . 97 — > 

</MeasurementValue> 
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</OtherInf ormat ion> 

<DataConversion  Type="Coef f icients">< ! -- 

DCTiCOE — > 

<Coefficients> 

<!--CO\N:l  is  implicit--> 

<DerivedFromPairSet>No</DerivedFromPairSet>< ! --C01 :N--> 

<Coef f icient 

N="0">0</Coefficient><!--CO:0--> 

<Coeff icient 

N="l">0.03125</Coefficient><! --CO-1 : .03125--> 

</ Coefficient s> 

</DataConversion> 

</Measurement> 

</DataConversionAttributes> 

</DataLink> 

<DataLink  Name="SPI">< ! — P-4\DLN: SPI — > 

<!--  P  Group  --> 

<PCMFormatAttributes> 

< ! --  D  Group  --> 

<PCMMeasurement s> 

< ! --D-4\DLN: SPI  is  implicit--> 
</PCMMeasurement s> 

</PCMFormatAttributes> 

</DataLink> 

<Comment>I  hope  this  flies . </Comment>< ! --COM:  I  hope  this 
flies . --> 

</Tmats> 

< ! --  Last  revised  on:  v3  2012/02/21  --> 
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APPENDIX  9-D 
Floating  Point  Formats 


D.l.  Introduction 


Table  D-1  provides  a  summary  of  floating  point  formats.  Details  of  each  format  are 
shown  on  the  pages  following  the  table. 


Table  D-1.  Floating  Point  Formats 

Type 

Size 

Radix 

Sign 

Exponent 

Fraction 

Bias 

Formula 

IEEE 32 

32 

2 

1 

8 

23 

127 

(-1®)(1.F)(2(E"'27)) 

IEEE 64 

64 

2 

1 

11 

52 

1023 

(-1^)(1.F)(2(E“'°23)) 

1750A 32 

32 

2 

0 

8 

24 

0 

(0.F)(2E) 

1750A 48 

48 

2 

0 

8 

40 

0 

(0.F)(2E) 

DEC 32 

32 

2 

1 

8 

23 

128 

(-1^)(0.1F)(2(E"'28)) 

DEC 64 

64 

2 

1 

8 

55 

128 

(-1®)(0.1F)(2(E"'28>) 

DEC 64G 

64 

2 

1 

11 

52 

1024 

(-1®)(0.1F)(2(E"'°24)) 

IBM 32 

32 

16 

1 

7 

24 

64 

(-1^)(0.F)(16(E“'^^)) 

IBM 64 

64 

16 

1 

7 

56 

64 

(-1^)(0.F)(16(^“®^)) 

TI 32 

32 

2 

1 

8 

24 

0 

((-2)S-h(0.F))(2E) 

TI_40 

40 

2 

1 

8 

32 

0 

((-2f  +  (0.F))(2^) 

D.2.  IEEE  754  32-Bit  Single  Precision  Floating  Point 


S 

Exponent 

Fraction 

1 

2  9 

10  32 

2"'  2“23 

Value  =  (-1^)(1.F)(2(e-'27)) 

where  S  =  sign:  0  =  Positive,  1  =  Negative 

Exponent  =  power  of  2  with  bias  of  127 
Fraction  =  F  portion  of  23-bit  fraction  l.F 
0:  E  =  0,  F  =  0 


D.3.  IEEE  754  64-Bit  Double  Precision  Floating  Point 


S 

Exponent 

Fraction 

1 

2  12 

13  64 

2"'  2“^2 

Value  =  (-1^)(1.F)(2(E“'°23)) 

where  S  =  sign:  0  =  Positive,  1  =  Negative 

Exponent  =  power  of  2  with  bias  of  1023 
Fraction  =  F  portion  of  52-bit  fraction  l.F 
0:  E  =  0,  F  =  0 
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D.4.  MIL-STD-1750A  32-Bit  Single  Precision  Floating  Point 


s 

Fraction 

Exponent 

1 

2  24 

25  32 

2"’  2"23 

Value  =  (0.F)(2E) 

where  Exponent  =  2’s  complement  power  of  2 
S  =  sign:  0  =  Positive,  1  =  Negative 

S  -I-  Fraction  =  Normalized,  2’s  complement  F  portion  of  24-bit  fraction  O.F  (Bit  2  MUST 
be  set  for  positive,  clear  for  negative) 

0:F  =  0 


D.5.  MIL-STD-1750A  48-Bit  Double  Precision  Floating  Point 


S 

Fraction  (MSW) 

Exponent 

Fraction  (LSW) 

1 

2  24 

25  32 

33  48 

2“^  2"23 

2-24  2-31 

Value  =  (O.F)(2^) 

where  Exponent  =  2’s  complement  power  of  2 
S  =  sign:  0  =  Positive,  1  =  Negative 

S  -I-  Fraction  =  Normalized,  2’s  complement  F  portion  of  40-bit  fraction  O.F  (Bit  2  MUST 
be  set  for  positive,  clear  for  negative) 

0:F  =  0 


D.6.  DEC  32-Bit  Single  Precision  Floating  Point 


Exponent 

Fraction 

1 

2  9 

10  32 

2-2  2-2-^ 

Value  =  (-1^)(0.1F)(2('^-i28)) 

where  S  =  sign:  0  =  Positive,  1  =  Negative 

Exponent  =  power  of  2  with  bias  of  128 
Fraction  =  F  portion  of  23 -bit  fraction  O.IF 
0:S  =  0&F  =  0&E  =  0 


D.7.  DEC  64-Bit  Double  Precision  Floating  Point 


m 

Exponent 

Fraction 

1 

2  9 

10  64 

2-2  2-3^ 

Value  =  (-1^)(0.1F)(2('^“128)) 

where  S  =  sign:  0  =  Positive,  1  =  Negative 
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Exponent  =  power  of  2  with  bias  of  128 
Fraction  =  F  portion  of  5 5 -bit  fraction  O.IF 


0:S  =  0&F  =  0&E  =  0 


D.8.  DEC  64-Bit  “G”  Double  Precision  Floating  Point 


s 

Exponent 

Fraction 

1 

2  12 

13  64 

2-2  2-53 

Value  =  (-1^)(0.1F)(2('^“1°24)) 

where  S  =  sign:  0  =  Positive,  1  =  Negative 

Exponent  =  power  of  2  with  bias  of  1024 
Fraction  =  F  portion  of  52-bit  fraction  O.IF 
0:S  =  0&F  =  0&E  =  0 


D.9.  IBM  32-Bit  Single  Precision  Floating  Point 


S 

Exponent 

Fraction 

1 

2  8 

9  32 

2”'  2~^‘^ 

Value  =  (-1^)(0.F)(16('^“^^)) 

where  S  =  sign:  0  =  Positive,  1  =  Negative 

Exponent  =  power  of  16  with  bias  of  64 

Fraction  =  Normalized  F  portion  of  24-bit  fraction  O.F  (Bits  9-12  cannot  be  all  zero) 
0:F  =  0 


D.IO.  IBM  64-Bit  Double  Precision  Floating  Point 


m 

Exponent 

Fraction 

1 

2  8 

9  64 

2”'  2~^^ 

Value  =  (-1^)(0.F)(16(^“^^)) 

where  S  =  sign:  0  =  Positive,  1  =  Negative 

Exponent  =  power  of  16  with  bias  of  64 

Fraction  =  Normalized  F  portion  of  56-bit  fraction  O.F  (Bits  9-12  cannot  be  all  zero) 
0:F  =  0 


D.II.  TI  (Texas  Instruments)  32-Bit  Single  Precision  Floating  Point 


Exponent 

B 

Fraction 

1  8 

9 

10  32 

2"'  2"23 

Value  = 


D-3 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  9,  July  2017 


where  Exponent  =  2’s  complement  power  of  2 
S  =  sign:  0  =  Positive,  1  =  Negative 
Fraction  =  2’s  complement  F  portion  of  24-bit  fraction  l.F 
0:E  =  -128 

D.12.  TI  (Texas  Instruments)  40-Bit  Extended  Precision  Floating  Point 


Exponent 

S 

Fraction 

1  8 

9 

o 

o 

2"'  2"3i 

Value  = 

where  Exponent  =  2’s  complement  power  of  2 
S  =  sign:  0  =  Positive,  1  =  Negative 
Fraction  =  2’s  complement  F  portion  of  32-bit  fraction  l.F 
0:E  =  -128 
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APPENDIX  9-E 

Derived  Parameter  Specification 

E.l.  Derived  Parameter  Definition 

Derived  parameters  are  measurements  that  do  not  appear  in  any  data  stream;  instead,  they 
are  calculated  from  telemetry  measurements  in  a  data  stream,  numeric  constants,  and/or  other 
derived  measurements.  In  a  Telemetry  Attributes  Transfer  Standard  (TMATS)  file,  derived 
measurements  will  only  have  entries  in  the  C  group;  the  other  TMATS  groups  containing 
measurement  names  that  link  to  C  group  entries  only  include  telemetry  measurements. 

Derived  parameters  are  defined  using  the  Algorithm  Type  (C-d\DPAT)  and  Algorithm 
(C-d\DPA)  attributes  in  the  Derived  Parameter  section  of  the  TMATS  C  group.  They  can  be 
defined  in  one  of  two  methods.  The  first  method  to  specify  the  name  of  an  algorithm  (“function 
style”)  and  the  second  method  is  to  specify  a  text  string  of  the  algorithm  itself  (“formula  style”). 
Both  of  these  methods  are  currently  used  in  telemetry  processing  systems. 

In  function  style.  Algorithm  Type  is  set  to  “N”  and  Algorithm  contains  the  name  of  a 
function,  which  will  be  one  of  the  mathematical  functions  or  operators  as  defined  in  the  derived 
algorithm  grammar  shown  in  this  appendix.  The  Input  Measurand  attributes  (C-d\DP\N  and  C- 
d\DP-n)  and  Input  Constant  attributes  (C-d\DPC\N  and  C-d\DPC-n)  are  used  to  specify  the 
arguments  needed  by  the  named  function  (measurements  and  numeric  constants,  respectively,  as 
defined  in  the  derived  algorithm  grammar  in  this  appendix).  The  Trigger  Measurand  and 
Number  of  Occurrences  attributes  are  used  to  specify  when  and  how  often  the  derived  parameter 
will  be  calculated. 

In  formula  style.  Algorithm  Type  is  set  to  “A”  and  Algorithm  contains  the  actual 
function,  given  according  to  the  derived  algorithm  grammar  defined  in  this  appendix.  The  Input 
Measurand  attributes  and  Input  Constant  attributes  are  not  used.  The  Trigger  Measurand  and 
Number  of  Occurrences  attributes  are  used  to  specify  when  and  how  often  the  derived  parameter 
will  be  calculated. 

E.2.  Derived  Algorithm  Grammar:  Components 

Derived  algorithm  grammar  is  from  the  four  components  listed  below.  The  derived 
algorithm  may  be  any  combination  of  operators,  functions,  measurements,  and  numeric  constants 
strung  together  using  the  guidelines  in  this  document  to  create  complex  mathematical 
expressions  (see  Subsection  E.6.b).  Sample  syntaxes  for  the  Yet  Another  Compiler  Compiler 
(Yacc)  grammar  and  Lexicon  (Lex)  grammar  are  provided  in  Section  E.8. 

a.  Operators  (Section  E.3) 

b.  Numeric  Constants  (Section  E.4) 

c.  Measurements  (Section  E.5) 

d.  Mathematical  Lunctions  (Section  E.6). 
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E.3.  Operators 

Operators  are  simply  mathematical  functions  that  have  a  special  syntax  in  the  grammar. 
They  have  operator  symbol(s)  that  have  well-defined  arguments  and  return  a  value  as  a  result. 
Logical  operators  are  merely  functions  that  return  a  value  of  0  and  non-zero  for  false  and  true 
respectively. 


E.3.a.  Arithmetic  Operators 


Table  E-1.  Arithmetic  Operators 

Operator 

Description 

Example 

-1- 

Addition  (Sum) 

A-i-B 

- 

Subtraction  (Difference) 

A-B 

* 

Multiplication  (Product) 

A*B 

/ 

Division  (Quotient) 

A/B 

% 

Modulus  (Remainder) 

A%B 

** 

Exponentiation 

A  **  B 

E.3.b.  Bit  Manipulation  Operators 


Table  E-2.  Bit  Manipulation  Operators 

Operator 

Description 

Example 

1 

Bit-wise  OR 

AIB 

& 

Bit-wise  AND 

A&B 

A 

Bit-wise  XOR 

A^B 

~ 

Bit-wise  NOT 

~A 

« 

Bit-wise  Eeft  Shift 

A«B 

» 

Bit-wise  Right  Shift 

A»B 

E.3.C.  Relational  Operators 


Table  E-3.  Relational  Operators 

Operator 

Description 

Example 

=  = 

Equal  To 

A  =  =  B 

!= 

Not  Equal  To 

A  !=B 

<= 

Eess  Than  or  Equal  To 

A<=B 

>= 

Greater  Than  or  Equal  To 

A>=B 

< 

Eess  Than 

A<B 

> 

Greater  Than 

A>B 

II 

Eogical  OR 

AIIB 

&& 

Eogical  AND 

A&&B 

! 

Eogical  NOT  (Negation) 

!A 
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E.3.d.  Ternary  (if  then  else)  Operator 


Table  E-4.  Ternary  (if  then  else)  Operator 

Operator 

Description 

Example 

?; 

Ternary  Operator  (if-then-else) 

A?B  :  C 

E.3.e.  Associativity  Operator 


Table  E-5.  Associativity  Operator 

Operator 

Description 

Example 

() 

Associativity 

(A  -1-  B)  *  C 

E.3.f.  Precedence  and  Associativity  of  Operators  Erom  Highest  to  Eowest 


Table  E-6.  Precedence  and  Associativity  of  Operators  from 

Highest  to  Lowest 

Operators 

Associativity 

() 

Eeft  to  right 

-(UNARY) 

Right  to  left 

!  ~ 

Right  to  left 

** 

Eeft  to  right 

& 

Eeft  to  right 

A 

Eeft  to  right 

1 

Eeft  to  right 

*/% 

Eeft  to  right 

-1-  - 

Eeft  to  right 

«  » 

Eeft  to  right 

<><=>= 

Eeft  to  right 

=  =  != 

Eeft  to  right 

&& 

Eeft  to  right 

II 

Eeft  to  right 

?; 

Right  to  left 

9 

Eeft  to  right 

E.4.  Numeric  Constants 

Numeric  constants  are  simply  numbers  used  in  the  calculations. 


Table  E-7  Numeric  Constants  (Examples) 

Description 

Examples 

Any  string  of  characters  that  contains  only  numerals 

1234 

0 

Any  string  of  characters  that  contains  only  numerals  and  a-f 
preceded  by  "Ox"  (hex) 

0xl2ab 

0x1 
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Any  string  of  characters  that  contains  only  numerals  and  a 
single 

1.2 

1. 

.2 

Any  string  of  characters  that  contains  only  numerals,  in 

l.OE-i-10 

scientific  notation. 

lOE-10 

.le6 

Note:  As  in  the  TMATS  standard  itself,  alphanumeric  data  items  are  case 
insensitive;  either  upper  or  lower  case  characters  are  allowed. 

E.5.  Measurements 


Measurements  may  be  telemetry  measurements  or  other  derived  measurements. 


Table  E-8.  Measurements  (Examples) 

Description 

Examples 

Any  string  of  characters  beginning  with  an  alphabetic 
character  and  containing  only  alphanumerics  and 

AOO.l 

A$1 

Any  string  of  characters  that  is  quoted  with  "  and  does  not 
contain  ". 

"0001" 

“measurement  ’quoted’, 
though  this  is  insane  -  it  is 
legal” 

Any  string  of  characters  quoted  with  '  and  does  not  contain 

I 

'Air  Speed' 

Any  string  of  characters  that  contains  only  numerals  and  at 
least  one  alphabetic  character.  This  differs  from  hex 
because  it  does  not  begin  with  “Ox”. 

00  A 1 

OX  (this  is  ok,  because  it 
does  not  have  a  number 
after  “OX”) 

Note:  As  in  the  TMATS  standard  itself,  alphanumeric  data  items  are  case  insensitive; 
either  upper  or  lower  case  characters  are  allowed. 

E.6.  Mathematical  Functions 

E.6.a.  Mathematical  Function  Format 

Mathematical  functions  are  numerical  functions  that  take  some  input,  perform  a  specific 
calculation,  and  return  a  value  as  the  result.  Each  mathematical  function  has  the  form 
“name(argl,arg2,...)”  that  identifies  a  well-defined  name  and  contains  argument(s)  that  are 
separated  by  commas  and  surrounded  by  parentheses.  A  list  of  selected  mathematical  functions 
is  provided  in  Table  E-9. 

E.6.b.  Complex  Use  of  Functions 

Examples  of  how  functions  can  be  used  in  mathematical  expressions  are: 

e.  A*(SIN(B/C)-i-D) 

f.  A*3.0 

g.  "0001"*A-i-~B 

h.  A<B  II  B«C  ?  D  :  E 
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Table  E-9.  Table  of  Selected  Mathematical  Functions 

Name 

Description 

cos“^(x)  in  range  [0,7i],  x  G  [-1,1]. 

sin“^(x)  in  range  {-nil,  7i/2],  x  G  [-1,1]. 

atan(x) 

tan"'(x)  in  range  [-7i/2, 7i/2] 

atan2(y,x) 

tan"'(y/x)  in  range  [-71, 71] 

ceil(x) 

smallest  integer  not  less  than  x 

cos(x) 

cosine  of  x 

cosh(x) 

hyperbolic  cosine  of  x 

exp(x) 

exponential  function,  computes  ex 

fabs(x) 

absolute  value  Ixl 

floor(x) 

largest  integer  not  greater  than  x 

fmod(x) 

floating  point  remainder 

frexpx(d) 

Eind  X  in  [.5,1]  and  y  so  that  d  =  x*pow(2,y),  return  x 

frexpy(d) 

Eind  X  in  [.5,1]  and  y  so  that  d  =  x*pow(2,y),  return  y 

ldexp(d,i) 

returns  d*pow(2,i) 

log(x) 

natural  logarithm  ln(x),  x  >  0 

loglO(x) 

base- 10  logarithm  loglO(x),  x  >  0 

max(x,y) 

if  x>y,  then  return  x,  else  return  y 

min(x,y) 

if  x<y,  then  return  x,  else  return  y 

modfd(d) 

returns  integral  part  of  d 

modfp(d) 

returns  fractional  part  of  d 

pow(x,y) 

compute  a  value  taken  to  an  exponent,  xy.  An  error  occurs  when 
x<=0  and  y  <=  0  or  x  <  0  and  y  is  not  an  integer 

sin(x) 

sine  of  x 

sinh(x) 

hyperbolic  sine  of  x 

sqrt(x) 

square  root  Vx,  x>=  0 

tan(x) 

tangent  of  x 

tanh(x) 

hyperbolic  tangent  of  x 

E.7.  Derived  Grammar  Syntax  Overview 

The  following  grammar,  strictly  speaking,  does  not  match  the  C  language.  Although 
loosely  based  on  C,  the  grammar  attempts  to  follow  the  “spirit”  of  the  C  language.  The  grammar 
contains  three  terminal  symbols  (MEASUREMENT,  NUMERIC_CONSTANT,  and 
EUNCTION_NAME)  not  defined  here,  but  easily  understood  by  their  names.  The  grammar 
contains  two  non-terminals,  expression  and  expression-list,  which  define  the  entire  grammar. 

The  “I”  operator  used  in  the  grammar  denotes  a  choice  meaning  “this  or  that  or  ...”  Quoted 
strings  are  literal  tokens  of  the  grammar. 
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expression: 

expression  '-i-'  expression 
I  expression expression 
I  expression  expression 
I  expression  7'  expression 
I  expression  T  expression 
I  expression  '&'  expression 
I  expression '%'  expression 
I  expression  '**'  expression 
I  expression  '?'  expression  expression 
I  expression  '<'  expression 
I  expression  ’>'  expression 
I  expression  '<='  expression 
I  expression  '>='  expression 
I  expression  '!='  expression 
I  expression  '=='  expression 
I  expression  '&&'  expression 
I  expression  'll'  expression 
I expression 
I '!'  expression 
I expression 
I '  ('  expression  ') ' 

I  MEASUREMENT 
I  NUMERIC_CONSTANT 
I  EUNCTION_NAME  '('  expressionjist ')' 
I  EUNCTION_NAME  '  (' ')' 

expression-list: 

expression 

I  expression-list expression 


Eigure  E- 1 .  Grammar  Syntax 


E.8.  Grammar  Examples 

Examples  of  Yacc  and  Eex  grammar  are  shown  in  Eigure  E-2  and  Eigure  E-3, 
respectively.  The  grammar  will  recognize  the  derived  syntax;  that  is,  they  will  report  whether  or 
not  a  given  text  string  is  valid  syntax;  however,  the  examples  are  not  intended  to  be  complete;  in 
other  words,  they  will  not  compile  or  perform  the  calculation.  The  user  needs  only  to  build  a 
program  around  them  in  order  to  use  them;  a  simple  example  “main”  is  shown  in  Eigure  E-4. 

The  Yacc  is  a  parser  generator  developed  by  Stephen  C.  Johnson  at  American  Telephone 
and  Telegraph  (AT&T)  for  the  Unix  operating  system.  It  generates  a  parser,  in  C  language  code, 
based  on  an  analytic  grammar  written  in  a  notation  similar  to  Backus-Naur  Eorm  (BNE).  The 
Eex,  a  program  that  generates  lexical  analyzers,  is  commonly  used  along  with  the  Yacc  parser 
generator.  Originally  written  by  Eric  Schmidt  and  Mike  Eesk,  Eex  is  the  standard  lexical 


E-6 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  9,  July  2017 


analyzer  generator  on  many  Unix  systems.  A  tool  exhibiting  its  behavior  is  specified  as  part  of 
the  Portable  Operating  System  Interface  standard. 


%{ 

%} 

%token  ERR 
%token  NAME 
%token  CONSTANT 

//  Operator  Precedence  Rules  (Eowest  Eirst,  Highest  East) 
%left 

%right  COND  '?' 

%left  OR 
%left  AND 

%left  EQUAE  NOTEQUAE 

%left  '<’  ’>'  EESSEQUAE  GREATEREQUAE 

%left  ESHIET  RSHIET 

%left 

%left  '/' '%' 

%left  T 

%left 

%left 

%left  POWER 
%right 

%right  UMINUS 
//  Definition  of  Rules 

%% 

expression: 

expression  '-r'  expression 
I  expression expression 
I  expression  expression 
I  expression  expression 
I  expression  '&'  expression 
I  expression '%'  expression 
I  expression  ESHIET  expression 
I  expression  RSHIET  expression 
I  expression  POWER  expression 
I  expression  '?'  expression  expression  %prec  COND 


Eigure  E-2.  Yacc  Grammar  Example,  Page  1  of  2 
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I expression  %prec  UMINUS 
I'!'  expression 
I expression 
I '('  expression ')' 

I  NAME 
I  CONSTANT 

I  NAME  '('  expression_list ')' 

I  NAME '(' ')' 

I  expression  '<'  expression 
I  expression  ’>'  expression 
I  expression  EESSEQUAE  expression 
I  expression  GREATEREQUAE  expression 
I  expression  NOTEQUAE  expression 
I  expression  EQUAE  expression 
I  expression  OR  expression 
I  expression  AND  expression 

expression_list: 

expression 

I  expression_list expression 


%% 


Eigure  E-3.  Yacc  Grammar  Example,  Page  2  of  2 
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%{ 

#include  “y.tab.h” 

%} 

%% 

[\t\n  ] 

{} 

\=\= 

[  return(EQUAL);  } 

//  Equal  To 

\!\= 

{  return(NOTEQUAL);  } 

//  Not  Equal  To 

\<\= 

{  return(LESSEQUAL);  } 

//  Less  Than  or  Equal  To 

\>\= 

[  return(GREATEREQUAL);  }  //  Greater  Than  or  Equal  To 

(\*\*) 

{  retum(POWER);  } 

//  Power  (EORTRANish) 

\l\l 

[  retum(OR);  } 

//  Logical  OR 

\&\& 

[  retum(AND);  } 

//  Logical  AND 

\<\< 

[  retum(LSHIPT);  } 

//  Bitwise  Left  Shift 

\>\> 

{  retum(RSHIPT);  } 

//  Bitwise  Right  Shift 

\> 

//  Greater  Than 

\< 

//  Less  Than 

\! 

//  Logical  Negation 

\? 

//  Ternary  Operator  ? 

\: 

//  Ternary  Operator : 

\% 

//  Modulus  (Remainder) 

\, 

//  Comma  Operator  (function) 

\* 

//  Multiplication  (Product) 

V 

//  Division  (Quotient) 

\-h 

//  Addition  (Sum) 

\- 

//  Subtraction  (Difference) 

\l 

//  Bitwise  OR 

\& 

//  Bitwise  AND 

//  Bitwise  XOR 

\~ 

\( 

//  Bitwise  NOT 

\) 

[  retum(yytext[0]);  } 

Figure  E-4.  Lex  Grammar  Example,  Page  1  of  2 
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Figure  E-5.  Lex  Grammar,  Page  2  of  2 


Figure  E-6.  Example  Program  (Main) 


E.9.  Telemetry  Attributes  Transfer  Standard  (TMATS)  Examples 

In  the  following  examples,  input  measurement  names  are  in  the  form  of  MA,  MB,  and 
MC.  Derived  parameter  names  are  in  the  form  of  DMA,  DMB,  and  DMC. 
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E.9.a.  TMATS  Example  1 

DMA  =  MA  -I-  MB 


Function  style 

C-1\DCN:DMA; 

C-1\DCT:DER; 

C-1\DPAT:N; 

C-l\DPA:-i-; 

C-1\DPTM:MB; 

C-l\DPNO:l; 

C-1\DP\N:2; 

C-1\DP-1:MA; 

C-1\DP-2:MB; 

Formula  style 

C-2\DCN:DMA; 

C-2\DCT:DER; 

C-2\DPAT:A; 

C-2\DPA:MA  -i-  MB; 

C-2\DPTM:MB; 

C-2\DPNO:l; 


Derived  parameter 
Derived  conversion  type 
Name  of  algorithm  will  be  given 
Addition  operator 

Measurement  MB  triggers  the  calculation 
Every  sample  of  MB  triggers  the  calculation 
Two  input  measurements 


Algorithm  will  be  given 
Algorithm  syntax 


E.9.b.  TMATS  Example  2 

DMB  =  MC  /  MD 


Function  style 

C-3\DCN:DMB;  Derived  parameter 

C-3\DCT:DER;  Derived  conversion  type 

C-3\DPAT:N;  Name  of  algorithm  will  be  given 

C-3\DPA:/;  Division  operator 

C-3\DPTM:MD;  Measurement  MD  triggers  the  calculation 

C-3\DPNO:  1 ;  Every  sample  of  MD  triggers  the  calculation 

C-3\DP\N:2;  Two  input  measurements 

C-3\DP-1:MC; 

C-3\DP-2:MD; 

Note:  In  function  style,  the  algorithm  determines  the  meaning  of  the  input  measurements.  In  this 
example,  the  division  algorithm  assigns  the  first  input  measurement  as  the  dividend  and  the 
second  input  measurement  as  the  divisor. 
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Formula  style 

C-4\DCN:DMB; 

C-4\DCT:DER; 

C-4\DPAT:A;  Algorithm  will  be  given 

C-4\DPA:MC  /  MD;  Algorithm  syntax 

C-4\DPTM:MD; 

C-4\DPNO:l; 

E.9.e.  TMATS  Example  3 

DMC  =  square  root  of  ME 

Function  style 

C-5\DCN:DMC; 

C-5\DCT:DER; 

C-5\DPAT:N; 

C-5\DPA:SQRT; 

C-5\DP\N:1; 

C-5\DP-1:ME; 

Formula  style 

C-6\DCN  :DMC; 

C-6\DCT  :DER; 

C-6\DPAT:A; 

C-6\DPA:SQRT(ME);  Algorithm  syntax 

Note:  The  trigger  measurand  is  not  given;  there  is  only  one  input,  whieh  must  trigger  the 
ealeulation. 

E.9.d.  TMATS  Example  4 

DMD  =  MF*(SIN(MG/MH)-i-MJ) 


Derived  parameter 
Derived  eonversion  type 
Name  of  algorithm  will  be  given 
Square  root  funetion 
One  input  measurement 


Algorithm  will  be  given 


Function  style 

C-7\DCN:XA; 

C-7\DCT:DER; 

C-7\DPAT:N; 

C-7\DPA:/; 

C-7\DP\N:2; 

C-7\DP-1:MG; 

C-7\DP-2:MH; 

C-8\DCN:XB; 

C-8\DCT:DER; 

C-8\DPAT:N; 


Derived  parameter 
Derived  eonversion  type 
Name  of  algorithm  will  be  given 
Division  operator 
Two  input  measurements 


Derived  parameter 
Derived  eonversion  type 
Name  of  algorithm  will  be  given 
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C-8\DPA:SIN; 

C-8\DP\N:1; 

C-8\DP-1:XA; 

C-9\DCN:XC; 

C-9\DCT:DER; 

C-9\DPAT:N; 

C-9\DPA:-h; 

C-9\DP\N:2; 

C-9\DP-1:XB; 

C-9\DP-2:MJ; 

C-10\DCN:DMD; 

C-10\DCT:DER; 

C-10\DPAT:N; 

C-10\DPA:*; 

C-10\DP\N:2; 

C-10\DP-1:ME; 

C-10\DP-2:XC; 

Note:  In  this  example,  several  steps  are  needed,  each  generating  an  intermediate  result  (XA,  XB, 
and  XC),  before  the  derived  parameter  is  obtained.  This  method  is  shown  only  for  illustrative 
purposes  and  is  not  recommended.  If  this  function  is  needed,  a  custom  algorithm  should  be 
written  to  implement  it.  Then  the  function  style  could  be  used,  as  follows: 

C- 1 1\DCN:DMD;  Derived  parameter 

C- 1 1\DCT:DER;  Derived  conversion  type 

C-1 1\DPAT:N;  Name  of  algorithm  will  be  given 

C- 1 1\DPA:NEWAEG;  Name  of  custom  algorithm 

C-11\DPTM:MJ; 

C-ll\DPNO:l; 

C  - 1 1  \DP\N :  4 ;  Eour  input  measurements 

C-11\DP-1:ME; 

C-11\DP-2:MG; 

C-11\DP-3:MH; 

C-11\DP-4:MJ; 

Formula  style 

C-12\DCN:DMD; 

C-12\DCT:DER; 

C- 1 2\DPAT : A;  Algorithm  will  be  given 

C-12\DPA:ME*(SIN(MG/MH)-i-MJ); 

C-12\DPTM:MJ; 

C-12\DPNO:l; 


Sine  function 

One  input  measurement 

Derived  parameter 
Derived  conversion  type 
Name  of  algorithm  will  be  given 
Addition  operator 
Two  input  measurements 

Derived  parameter 
Derived  conversion  type 
Name  of  algorithm  will  be  given 
Multiplication  operator 
Two  input  measurements 
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E.IO.  Glossary  of  Terms 

Backus-Naur  Form:  A  metasyntax  used  to  express  context-free  grammar;  that  is,  a  formal  way 
to  describe  formal  languages.  John  Backus  and  Peter  Naur  developed  a  context  free  grammar  to 
define  the  syntax  of  a  programming  language  by  using  two  sets  of  rules:  i.e.,  lexical  rules  and 
syntactic  rules 

Compiler:  A  computer  program  (or  set  of  programs)  that  transforms  source  code  written  in  a 
computer  language  (the  source  language)  into  another  computer  language  (the  target  language, 
often  having  a  binary  form  known  as  object  code). 

Compiler  (Compiler  Generator):  A  tool  that  creates  a  parser,  interpreter,  or  compiler  from 
some  form  of  formal  description.  The  earliest  and  still  most  common  form  of  compiler-compiler 
is  a  parser  generator,  whose  input  is  a  grammar  (usually  in  BNF)  of  a  programming  language, 
and  whose  generated  output  is  the  source  code  of  a  parser. 

Computer  Programs:  Also  called  software  programs,  or  just  programs,  are  instructions  for  a 
computer. 

Grammar:  A  set  of  formation  rules  that  describe  which  strings  formed  from  the  alphabet  of  a 
formal  language  are  syntactically  valid  within  the  language. 

Interpreter:  Normally  means  a  computer  program  that  executes  instructions  written  in  a 
programming  language. 

Parser  Generator:  See  Compiler. 

Parsing:  The  process  of  analyzing  a  sequence  of  tokens  (for  example,  words)  to  determine  their 
grammatical  structure  with  respect  to  a  given  (more  or  less)  formal  grammar. 

Programming  Language:  A  machine-readable  artificial  language  designed  to  express 
computations  that  can  be  performed  by  a  machine,  particularly  a  computer. 

Source  Code:  Any  collection  of  statements  or  declarations  written  in  some  human-readable 
computer  programming  language. 

Unix:  A  computer  operating  system  originally  developed  in  1969  by  a  group  of  AT&T 
employees  at  Bell  Labs. 

Yet  Another:  In  hacker  jargon,  the  use  of  yet  another  as  a  way  of  padding  out  an  acronym  is 
fairly  common.  It  was  first  used  by  Stephen  C.  Johnson  in  the  late  1970s  in  naming  Yacc  as  a 
humorous  reference  to  the  proliferation  of  such  compiler-compilers  at  the  time. 

Yet  Another  Compiler  Compiler  (Yacc  ):  Supplied  with  Unix  and  Unix-like  systems. 
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APPENDIX  9-F 
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CHAPTER  10 

Digital  Recording  Standard 


10.1  General 

A  large  number  of  unique  and  proprietary  data  structures  has  been  developed  for  specific 
data  recording  applications  that  required  unique  decoding  software  programs.  The  activities  of 
writing  unique  decoding  software,  checking  the  software  for  accuracy,  and  decoding  the  data 
tapes  are  extremely  time-consuming  and  costly.  In  the  late  1990s,  the  test  ranges  started  to  see 
the  implementation  of  non-tape-based,  high-data-rate  recorders,  the  most  predominant  of  which 
were  solid-state  memory  devices.  Then,  as  high-data-rate  digital  recorders  were  fielded  and  as 
solid-state  technology  began  to  emerge,  the  Telemetry  Group  saw  the  need  and  formed  an  ad  hoc 
committee  for  a  computer-compatible  digital  data  acquisition  and  recording  standard. 

10.1.1  Digital  Recorder  Requirements 

There  is  a  need  for  a  digital  data  acquisition  and  recording  standard  (see  the  functional 
layout  at  Figure  10-1)  that  supports  a  broad  range  of  requirements,  including: 

a.  Data  download  and  interface 

b.  One  or  more  multiplexed  data  streams 

c.  One  or  more  single-data  streams 

d.  Data  format  definitions 

e.  Recorder  control 

f.  Media  declassification 

g.  Data  interoperability 
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Figure  10-1.  Functional  Layout  of  Digital  Recorder  Standard 


Specifically,  this  digital  recording  standard  shall  be  compatible  with  the  multiplexing  of 
both  synchronous  and  asynchronous  digital  inputs  such  as  pulse  code  modulation  and  Military 
Standard  (MIL-STD)  1553  data  bus,  time,  analog,  video.  Aeronautical  Radio,  Inc.  429,  discrete, 
and  Universal  Asynchronous  Receiver  and  Transmitter  containing  Recommended  Standard 
(RS)-232/422/485  communication  data.  This  digital  recording  standard  will  allow  use  of  a 
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common  set  of  playback/data  reduction  hardware/software  to  take  advantage  of  emerging 
random  access  recording  media. 


NOTE 


y 


Within  this  standard,  where  text,  figures,  or  tables  are  used 
to  provide  descriptions,  meaning,  and/or  explanations,  the 
text  shall  take  precedence  over  figures  and  tables. 


10.1.2  Interface  Levels 

The  purpose  of  this  chapter  is  to  establish  a  common  interface  standard  for  the 
implementation  of  digital  data  acquisition  and  recording  systems  by  the  organizations 
participating  in  the  Range  Commanders  Council  (RCC).  This  standard  does  not  imply  hardware 
architecture  such  as  the  coupling  of  data  acquisition,  multiplexing,  and  media  storage.  The 
required  interface  levels  are  contained  in  this  standard. 

a.  Data  Download  and  Electrical  Interface,  which  is  the  physical  interface  for  data  access,  is 
defined  in  Section  10.4. 

b.  Interface  File  Structure,  which  defines  data  access  structure,  is  described  in  Section  10.5. 

c.  Data  Format  Definition,  which  defines  data  types  and  packetization  requirements,  is 
defined  in  Section  10.6. 

d.  Recorder  Control  and  Status,  which  defines  command  and  control  mnemonics  (CCM), 
status,  and  their  interfaces,  is  described  in  Section  10.7. 

e.  Host  Platform  Interface  to  Recorder  Removable  Media  is  defined  in  Section  10.9. 

f.  Ground-Based  Recorder  Interface,  which  defines  unique  interoperability  requirements  of 
a  ground-based  recorder,  is  described  in  Section  10.10. 

g.  Data  Interoperability,  which  defines  requirements  for  the  annotation,  modification,  and 
exchange  of  recorded  data,  is  described  in  Section  10.11. 

10.2  Definitions 

As  of  RCC  106-13  published  June  2013,  the  definitions  that  in  previous  versions 
comprised  this  section  are  now  located  in  Appendix  10- A. 

10.3  Operational  Requirements 

On-board  recorders  are  the  basis  and  original  justification  for  this  standard.  This  section 
defines  the  requirements  for  on-board  recorders  to  be  in  100  percent  compliance. 

10.3.1  Recorder  Compliance  Requirements 

Table  10-1  and  Table  10-2  represent  the  mandatory  recorder  requirements  to  meet  100 
percent  compliance  with  this  standard.  Meeting  these  compliance  requirements  guarantees 
interoperability  of  recorders,  recorder  media,  and  recorded  data.  Optional  functions  and/or 
capabilities  are  not  shown  but  when  implemented  in  a  recorder  shall  be  in  accordance  with 
(lAW)  the  definitions  in  this  standard  in  order  to  meet  100  percent  compliance  of  this  standard. 
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Table  10-1.  On-Board  Recorder  Mandatory  Compliance  Requirements 

Applicable 
Compliance  Section 

F  unction/  Capability 

Recorder  Electrical  Interfaces 

10.3,  10.4 

Fibre  Channel  and/or  IEEE  1394b  Data  Download  Port 

10.3,  10.7 

Discrete  Lines  and/or  RS-232  and  422  Eull  Duplex  Communication 

10.3 

External  Power  Port 

Recorder  Download  Interface  Protocols 

10.4,  10.9 

Eibre  Channel  SCSI  and/or  IEEE  1394b  SCSFSBP-2 

Recorder  Control/Status  Interface  Protocols 

10.7 

Discrete  Control/Status  and/or  RS-232  and  422  Control/Status 

Removable  Memory  Module  (RMM)  Electrical  Interface  and  Power 

10.3,  10.9 

IEEE  1394b  Bilingual  Socket  or  Ethernet  8P8c/RJ45 

Commercial  Off-the-Shelf  (COTS)  Media  Electrical  Interfaces 

10.3 

COTS  Media  Interface 

RMM  Interface  Protocols 

10.9 

IEEE  1394b  SCSFSBP-2  or  IEEE  802.3  IPv4 

COTS  Media  Interface  Protocols 

10.3 

COTS  Media  Interface 

Recorder  Media/RMM/COTS  Media  Interface  File  Structure 

10.5 

Directory,  Pile  Structures,  and  Data  Organization 

10.3.7 

Directory  and  Pile  Table  Entries 

Packetization  and  Data  Format 

10.6 

Packet  Structures,  Generation,  Media  Commitment,  Time  Stamping, 
and  Data  Type  Pormats 

Data  Interoperability 

10.11 

Original  Recording  Piles 

Table  10-2. 

Ground-Based  Recorder  Mandatory  Compliance 
Requirements 

Applicable 
Compliance  Section 

F  unction/  Capability 

Recorder  Electrical  Interfaces 

10.10 

Ethernet 

Recorder  Remote  Interface  Protocols 

10.10,  10.4 

Internet  Small  Computer  Systems  Interface  (iSCSI)  and/or  Telnet 

COTS  Media  Electrical  Interfaces 

10.10 

COTS  Media  Interface 

COTS  Media  Interface  Protocols 

10.10 

COTS  Media  Interface 

Remote  Data  Access  Interface  File  Structure 

10.5 

Directory,  Pile  Structures,  and  Data  Organization 
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Table  10-2. 

Ground-Based  Recorder  Mandatory  Compliance 
Requirements 

Applicable 
Compliance  Section 

F  unction/  Capability 

10.3.7 

Directory  and  File  Table  Entries 

Packetization  and  Data  Format 

10.6 

Packet  Structures,  Generation,  Media  Commitment,  Time  Stamping, 
and  Data  Type  Formats 

Data  Interoperability 

10.11 

Original  Recording  Files 

10.3.2  Required  Configuration 

An  on-board  recorder,  as  a  minimum,  shall  provide  the  following  functionality. 

a.  Data  download  port 

b.  Recorder  control/maintenance  port 

c.  External  power  port 

The  required  data  download  port  interface  shall  be  lAW  Section  10.4.  This  combination 
will  allow  data  extraction  and  transfer  from  any  recorder  to  any  Section  10.4-compliant 
intermediate  storage  unit.  The  required  control  port  interface  shall  be  lAW  Section  10.7. 

10.3.3  Exclusions  to  Standard 

The  physical  size,  configuration,  and  form  factor  for  the  on-board  recorder  and  the  RMM 
are  not  controlled  by  this  standard.  Due  to  the  variation  in  capacity/rate/cost  requirements  of  the 
users,  this  standard  does  not  specify  the  technology  to  be  used  in  the  RMM  or  the  on-board 
recorder. 

10.3.4  Internal  System  Management 

Any  processing  performed  on  the  stored  data  by  the  on-board  recorder  (e.g.,  for  the 
purposes  of  internal  system  management,  error  detection  and  correction,  physical  frame 
formatting,  etc.)  shall  be  removed  from  the  stored  data  when  the  stored  data  is  downloaded  or 
transferred  from  storage  media. 

10.3.5  Data  Download 

On-board  recorders  may  have  an  RMM  capability  or  the  on-board  recorder  can  be 
removed  from  the  acquisition  platform  and  taken  to  a  ground  station  for  data  download.  Refer  to 
Subsection  10.4.1  for  recorder  download  and  electrical  interface.  Section  10.9  for  RMM 
interface,  and  Section  10.11  for  data  transfer  and  file  management. 

10.3.6  Host  Platform  Interface  to  Recorder  Media 

Interface  to  on-board  recorder  media  shall  be  accomplished  utilizing  IEEE  1394b  or 
Ethernet  interfaces.  Interface  connectors  lAW  Subsection  10.9.5  shall  be  provided  on  the  media 
to  allow  direct  download  of  data  to  the  host  computer  or  storage  device. 
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10.3.7  Required  File  Table  Entries 

Within  Seetion  10.5,  Table  10-7  File  Size,  File  Create  Date,  File  Create  Time,  and  File 
Close  Time  are  either  optional  or  ean  be  empty  (filled  with  0x2D)  if  data  is  unavailable.  Table 
10-7  has  been  adopted  from  Standardization  Agreement  (STANAG)  4575*  but  in  the  case  of 
Chapter  10  unless  Time  Type  is  OxFF  (time  data  packet)  and  the  time  data  packet  source  is  OxF 
(None)  date  and  time  will  always  be  available. 

10.3.7.1  File  Table  Entry  Conditions 

If  Table  10-6  Shutdown  value  is  OxFF  or  0x00  and  Time  Type  is  OxFF  and  the  time  data 
packet  source  is  not  OxF  File  Size,  File  Create  Date,  File  Create  Time,  and  File  Close  Time 
entries  shall  be  filled  in  their  entirety. 

10.3.8  Recorder  Setup  Configuration  File 

A  recorder  setup  configuration  file  (RSCF)  can  reside  on  the  recorder  or  optionally  reside 
in  the  RMM.  Recorder  setup  configuration  must  be  lAW  Chapter  9.  Recorder  setup 
configurations  shall  be  programmed  lAW  Section  10.7.  Optionally  the  recorder  can  be 
configured  from  a  Chapter  10  configuration  file  residing  in  the  RMM.  The  RMM  RSCF  will 
have  priority  over  setup  records  residing  in  the  recorder. 

10.3.8. 1  Recorder  Configuration  File  Location 

When  a  setup  record  transfer  to  a  recorder  is  made  via  the  RMM  Computer- Generated 
Data,  Format  1  setup  record  packet(s)  will  be  used.  The  RMM  shall  contain  a  directory  and  one 
directory  block  file  entry  lAW  Subsection  10.5.2. 

a.  All  directory  block  format  fields  shall  be  lAW  Table  10-6.  The  field  n  File  Entries  value 
shall  be  1 . 

b.  All  directory  entry  format  fields  shall  be  lAW  Table  10-7.  The  field  “Time  Type”  value 
shall  be  0x01,  System  time.  The  field  “Name”  value  shall  be: 

recorder_configuration_file_SAVE_n 

This  will  notify  the  recorder  to  use  the  recorder  configuration  transfer  file  for  the  next 
recording  and  store  the  setup  information  contained  within  the  file  to  non-volatile  memory  in  the 
recorder  pre-defined  setup  location  n,  where  n  is  a  value  of  0-15.  This  shall  be  the  equivalent  of 
sending  .TMATS  SAVE  [n]  and  .SETUP  [n]  commands. 

10.3.8.2  Recorder  Configuration  Eile  Structure 

The  RSCE  structure  will  only  contain  Computer-Generated  Data,  Eormat  1  setup  record 
packets.  More  than  one  packet  is  allowed  only  if  the  required  recorder  configuration  information 
exceeds  the  packet  size  limits  in  Subsection  10.6.1,  thus  forcing  more  than  one  Computer- 
Generated  Data,  Eormat  1  setup  record  packet.  The  standard  method  of  using  the  sequence 
counter  will  be  utilized  until  all  the  configuration  information  has  been  packetized. 


'  North  Atlantic  Treaty  Organization.  “NATO  Advanced  Data  Storage  Interface  (NADSI).”  STANAG  4575 
(Editions).  8  May  2009.  May  be  superseded  by  update.  Retrieved  3  June  2015.  Available  at 
http://www.nato.int/structur/AC/224/standard/4575/ag4  4575  E  ed3  nu.pdf. 
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10.3.8.3  Configuration  of  Recorder  from  RMM 

A  setup  record  may  reside  in  the  RMM  and  be  utilized  for  configuration  of  the  recorder. 

A  Computer-Generated  Data,  Format  1  setup  record  packet(s)  will  be  used.  The  RMM  shall 
contain  a  directory  and  at  least  one  directory  block  file  entry  lAW  Subsection  10.5.2. 

a.  All  directory  block  format  fields  shall  be  lAW  Table  10-6.  The  field  “n  File  Entries” 
value  shall  be  1 . 

b.  All  directory  entry  format  fields  shall  be  lAW  Table  10-7.  The  field  “Time  Type”  value 
shall  be  0x01,  System  time.  The  field  “Name”  value  shall  be: 

recorder_configuration_file_SETUP_RMM 

This  will  notify  the  recorder  to  configure  from  the  RMM.  The  RSCE  shall  NOT  be  able 
to  be  erased  by  the  recorder  .ERASE  or  DISCRETE  command. 

10.3.9  Recorder  Data  Streaming  Transport 

Data  streaming  transport  may  be  accomplished  across  the  Section  10.4  recorder 
download  and  electrical  interfaces  using  the  definitions  in  Section  10.2  and  commands  in 
Chapter  6.  Eor  ground-based  recorders,  this  will  be  accomplished  across  the  required  remote 
data  access  Ethernet  interface. 

The  active  configuration  of  the  recorder  can  be  detected  by  means  of  Chapter  1 1 
Computer-Generated  Data  Packet,  Eormat  4  Streaming  Configuration  packets  inserted  into  the 
reserved  channel  ID  0x0000. 

10.3.9.1  IP  Streaming 

The  network  interface,  such  as  Ethernet  can,  be  used  for  data  streaming  over  Internet 
Protocol  (IP)  using  either  User  Datagram  Protocol  (UDP/IP)  or  Transmission  Control  Protocol 
(TCP/IP).  This  shall  be  controlled  with  the  Chapter  6  PUBEISH  command. 

When  streaming  data  over  IP  networks,  the  Stream  Commit  Time  requirement  shall  apply 
to  the  time  at  which  the  data  is  made  available  for  transmission  by  the  network  subsystem. 


IP  Streaming  may  use  either  IPv4  or  IPv6. 


NOTE/% 

As  IP  networks  are  non-deterministic  with  respect  to  timing. 

packets  may  be  delayed,  lost,  and/or  resent,  which  may 

result  in  an  unpredictable  delay  between  the  packet  being 

made  available  for  transmission  and  it  being  received. 

The  IP  protocol  supports  low-level  packet  sizes  up  to  64  kb;  however, 
common  IP  transports  such  as  Ethernet  impose  restrictions  on  the  size  of  the 
maximum  transmission  unit  (MTU),  beyond  which  fragmentation  is  required 
It  is  generally  desirable  to  manage  streaming  data  so  that  fragmentation  is 
avoided.  Eor  Ethernet,  an  MTU  of  1500  bytes  is  common,  unless  “jumbo 
frames”  are  enabled,  in  which  case  an  MTU  of  around  9000  bytes  is  typical. 


An  IPv4  datagram  is  limited  to  65,507  bytes,  which  is  significantly  less  than  the 
maximum  size  of  a  Chapter  1 1  packet.  An  IPv6  datagram  may  support  “jumbograms”  that 
support  payloads  larger  than  the  maximum  permitted  Chapter  1 1  packet  size,  but  support  of  this 
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feature  is  not  guaranteed  by  every  IPv6  device.  A  UDP  transfer  header  shall  be  used  to  support 
all  valid  Chapter  1 1  packets  and  to  help  protect  against  undetected  data  loss. 

Three  UDP  transfer  header  formats  are  defined.  Format  1  has  been  supported  since  IRIG 
106-11  and  was  specifically  designed  to  support  streaming  data  from  a  recorder  to  a  monitoring 
station.  Format  2  is  documented  to  reflect  existing  but  legacy  hardware  but  is  not  recommended 
for  use  in  new  applications.  Format  3  has  been  designed  to  add  support  for  distributed 
acquisition  systems;  it  supports  streaming  both  to  and  from  the  recorder. 

Format  3  is  recommended  for  all  new  designs. 

10.3.9.1.1  Ethernet  Packet  Payload  Byte  Order 

The  byte  ordering  of  the  streamed  packet  payload  (i.e.,  the  Chapter  1 1  packets)  shall  be 
lAW  Subsection  10.5.3.2. 


NOTE^ 

The  IP,  TCP  and  UDP  network  headers  use 

“big  endian”  byte  ordering,  also  known  as 

r 

“network  byte  ordering”. 

The  byte  order  of  the  UDP/IP  transfer  header  is  explicitly  defined  as  part  of  the  definition 
of  the  header. 

10.3.9.1.2  Format  1,  UDP  Transfer  Header 

The  structure  shown  in  Figure  10-2  shall  be  used  for  Format  1  UDP  transfer  headers  in 
datagrams  containing  one  or  more  full  Chapter  1 1  data  packets.  The  UDP  transfer  header, 
Format  1  uses  “little  endian”  byte  ordering. 


Most  Significant  Bit  (msb)  Least  Significant  Bit  (Isb) 

31  8 

7  4 

3  0 

UDP  Message  Sequence  Number 

Type  of 
message 

Format 

Figure  10-2.  UDP  Transfer  Format  1  Header  for  Non-Segmented  Data 


The  structure  in  Figure  10-3  shall  be  used  for  Format  1  UDP  transfer  headers  in  UDP 
datagrams  containing  a  segmented  Chapter  1 1  data  packet. 


10-8 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  10,  July  2017 


msb 

Isb 

31 

8 

7 

4 

3  0 

UDP  Message  Sequence  Number 

Type  of 
message 

Format 

31 

24 

23  16 

15 

0 

Reserved 

Channel  Sequence 
Number 

Channel  ID 

Words 

Word  4 

msb 

Isb 

31 

0 

Segment  Offset 

Figure  10-3.  UDP  Transfer  Format  1  Header  for  Segmented  Data 


Format  (4  bits) 

0000:  Reserved 

0001:  Format  1  (This  format) 

0010:  Format  2 
0011:  Formats 
0100-1111:  Reserved 

Type  of  Message  (4  bits) 

0000:  Full  packets 
0001:  Segmented 
0010-1111:  Reserved 

UDP  Message  Sequence  Number  (24  bits).  Binary  value  incrementing  by  one  for  each 
UDP  message  even  if  segment  of  Chapter  10  packet. 

Channel  ID  (16  bits).  Segmented  packets  only,  channel  ID  of  the  data  in  the  Chapter  10 
packet. 

Channel  Sequence  Number  (8  bits).  Segmented  packets  only,  channel  sequence  number 
of  the  data  in  the  Chapter  10  packet. 

Reserved  (8  bits).  Reserved. 

Segment  Offset  (32  bits).  Segmented  packets  only,  position  of  the  data  in  the  Chapter  10 
packet. 

10.3.9.1.3  Format  1,  UDP  Chapter  11  Packet  Transfer 

When  more  than  one  complete  Chapter  1 1  packet  is  contained  within  a  UDP  datagram, 
there  shall  be  an  integral  number  of  Chapter  1 1  packets.  The  packets  shall  be  sent  in  the  same 
sequence  as  the  recording  segment  of  a  packet  and  shall  be  ordered  (segment  offset 
incrementing).  Figure  10-4  and  Figure  10-5  present  the  sequence  of  the  general  UDP  network 
transmission  of  full  or  segmented  packets. 
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UDP/IP  Headers 

UDP  Transfer  Header,  Format  1 

Chapter  1 1  Packet  1 


Chapter  1 1  Packet  N 

Figure  10-4.  UDP  Transfer  Format  1  (Full  Packets) 


UDP/IP  Headers 

UDP  Transfer  Header,  Format  1 

Chapter  1 1  Packet  Segment 

Figure  10-5.  UDP  Transfer  Format  1  (Segmented  Packet) 

10.3.9.1.4  Format  2,  UDP  Transfer  Header 

The  structure  shown  in  Figure  10-6  shall  be  used  for  Format  2  UDP  transfer  headers  in 
datagrams.  Format  2  uses  “big  endian”  or  network  byte  ordering  for  the  header: 


MSW 

ESW 

31 

8 

7  4 

3  0 

Sequence  Number 

Type 

Eormat 

31  24 

23 

0 

Segment  Offset 

Packet  Size 

31 

16 

15 

0 

Segment  Offset 

Channel  Number 

Eigure  10-6.  UDP  Trans! 

dr  Eormat  2  Header 

Format  (4  bits) 

0000:  Reserved 
0001:  Format  1 
0010:  Format  2  (This  format) 

0011:  Format  3 
0100-1111:  Reserved 

Type  of  Message  (4  bits) 

0000:  Chapter  1 1  packet  contains  a  complete  Chapter  10  packet 
0001:  Chapter  11  packet  contains  a  partial  Chapter  10  packet 
0010-1111:  Reserved 

UDP  Message  Sequence  Number  (24  bits).  Binary  value  incrementing  by  one  for  each 
Chapter  1 1  packet. 

Channel  ID  (16  bits).  Channel  ID  of  the  embedded  IRIG- 106  Chapter  1 1  packet. 

Packet  Size  (24  bits).  Size  of  the  complete  Chapter  1 1  packet  in  units  of  32  bits. 

Segment  Offset  (24  bits).  Offset  for  this  data  in  the  Chapter  1 1  packet  in  units  of  32  bits. 

As  shown  in  Figure  10-7,  all  Chapter  1 1  packets  shall  be  sent  contained  within  1  or  more 
UDP  datagrams.  Each  datagram  shall  contain  a  payload  of  1472  bytes  or  less.  Each  datagram 
shall  contain  1  or  more  whole  or  partial  Chapter  1 1  packets.  A  datagram  may  begin  and/or  end 
with  a  partial  Chapter  1 1  packet,  or  contain  a  single  partial  Chapter  1 1  packet.  A  datagram  may 
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contain  multiple  whole  Chapter  1 1  packets.  Every  whole  or  partial  Chapter  1 1  packet  contained 
within  a  UDP  datagram  is  prefixed  with  a  Version  2  UDP  transfer  header. 

UDP/IP  Headers 
UDP  Transfer  Header,  Format  2 
Chapter  1 1  Packet  Segment  N-1 
UDP  Transfer  Header,  Format  2 
Chapter  1 1  Packet  N 

UDP  Transfer  Header,  Format  2 _ 

Chapter  1 1  Packet  Segment  N-i-1 

Figure  10-7.  UDP  Transfer  Format  2  (Segmented  Packet) 


10.3.9.1.5  Format  3,  UDP  Transfer  Header 

The  structure  shown  in  Figure  10-8  shall  be  used  for  Format  3  UDP  transfer  headers  in 
UDP  datagrams.  Format  3  uses  “little  endian”  byte  ordering  for  the  header: 


msb 

Isb 

31 

16 

15 

8 

7  4 

3 

0 

Offset  to  Packet  Start 

Reserved 

SrcID  Fen 

Format 

Source  ID 

Datagram  Sequence  Number 

Figure  10-8.  UDP  Transfer  Format  3  Header 


Format  (4  bits) 

0000:  Reserved 
0001:  Format  1 
0010:  Format  2 
0011:  Format  3  (This  format) 

0100-1111:  Reserved 

SrcID  Fen  (4  bits).  Number  of  bits  in  the  Source  ID  field.  Permissible  values  are  0  to  4, 
which  defines  the  number  of  4-bit  “nibbles”  to  be  used  with  the  interpretation  shown  in 
Table  10-3. 


Table  10-3.  Source  Field  Lengths 

“SrcID  Len” 
Value 

Length  of  “Source 
ID”  (bits) 

Max.  Number 
of  Sources 

Length  of  Datagram 
Sequence  Number  (bits) 

0 

0 

I 

32 

1 

4 

16 

28 

2 

8 

256 

24 

3 

12 

4096 

20 

4 

16 

65536 

16 

The  purpose  of  this  field  is  to  provide  enough  information  to  detect  when  the  datagram 
sequence  number  “wraps”;  the  median  value  of  2  is  recommended  as  a  good  compromise 
between  the  maximum  number  of  sources  on  the  same  network  (which  is  controlled  by 
the  length  of  the  “Source  ID”  field)  and  resilience  against  undetected  “wrapping”,  which 
requires  a  large  datagram  sequence  number. 
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Offset  to  Packet  Start  (16  bits).  Offset,  in  bytes,  to  the  start  of  the  first  Chapter  1 1  packet 
within  the  datagram.  As  the  Format  3  UDP  transfer  header  is  8  bytes  in  length,  values 
less  than  8  cannot  refer  to  the  start  of  a  packet,  and  instead  are  used  to  designate  the 
conditions  indicated  in  Table  10-4. 


Table  10-4.  Offset  Field  Meanings 

Value 

Meaning 

0 

No  Chapter  1 1  packet  starts  in  this  datagram  (i.e.,  this  is  datagram  is 
entirely  a  partial  packet). 

1 

The  sending  device  has  no  information  about  whether  a  Chapter  1 1 
packet  starts  in  this  datagram. 

2 

The  datagram  size  is  an  IPv6  “jumbogram”  larger  than  64  kb  and  no 
Chapter  1 1  packet  starts  in  the  first  64  kb  of  the  jumbo  datagram. 

8  -  65,507 

The  first  byte  of  the  first  Chapter  1 1  packet  in  this  datagram  is 
located  at  this  offset  from  the  start  of  the  datagram. 

The  use  of  the  special  value  “1”  is  discouraged  except  in  the  case  of  “bridge”  or  routing 
devices  that  have  no  inherent  knowledge  of  Chapter  1 1  packet  structure. 

Source  ID  (0  to  16  bits,  depending  on  “SrcID  Len”  field).  Value  indicating  which  of  a 
number  of  devices  is  generating  this  packet  stream;  must  be  unique  on  the  network. 
Assignment  of  this  value  is  not  controlled  by  this  standard,  and  has  no  inherent  meaning 
other  than  as  an  identifier. 


Datagram  Sequence  Number  (16  to  32  bits,  depending  on  “SrcID  Len”  field).  This  is  a 
monotonically  increasing  sequence  number  for  each  datagram  sent.  This  sequence 
number  will  wrap  from  “all  Is”  to  0. 


The  core  features  of  the  original  Format  1  UDP  transfer 
header  can  be  provided  by  setting  “SrcID  Len”  to  0  and 
ignoring  the  ability  to  have  multiple  sources. 


10.3.9.1.6 Format  3,  UDP  Chapter  11  Packet  Transfer 

In  Format  3,  the  Chapter  1 1  packet  stream  may  be  packed  into  as  many  or  as  few  discrete 
UDP  datagrams  as  suits  the  implementation.  This  facilitates  the  use  of  datagrams  sized  to  fit  the 
MTU  of  the  transmission  medium  (e.g.,  Ethernet). 

10.3.9.2  TCP  Data  Transfer 

When  supporting  TCP/IP  streaming,  the  recorder  can  act  either  as  client  (i.e.,  it 
establishes  the  connection  to  the  remote  device)  or  a  server  (i.e.,  it  waits  for  a  connection  from 
the  remote  device).  When  acting  as  a  server,  the  default  port  for  TCP/IP  connections  is  defined 
to  be  (decimal)  10620. 

Using  TCP/IP,  Chapter  1 1  packets  are  transmitted  in  the  exact  same  format  (byte  for 
byte)  as  they  would  be  written  to  local  storage  media. 

The  data  availability  (e.g.,  the  channel  selection)  can  be  controlled  with  the  remote 
control  command:  .PUBLISH_TCP  (see  Chapter  6). 
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When  a  TCP  connection  is  first  established,  the  first  byte  transmitted  shall  be  the  first 
byte  of  a  Chapter  1 1  packet. 

10.3.9.3  Non-IP  Streaming 

Streaming  over  connections  that  do  not  support  IP  are  treated  identically  to  TCP/IP  data 
transfer  as  described  in  Subsection  10.3.9.2. 

Chapter  7  provides  a  Non-IP  Streaming  mode  for  Chapter  1 1  packets. 

10.3.10  Commercial  Off-the-Shelf  Media 

In  conjunction  with  an  on-board  recorder  and/or  a  multiplexer  when  an  RMM  or  internal 
on-board  recorder  media  is  not  used,  COTS  media  can  be  used  for  recording  media.  The  COTS 
media  shall  be  accessible  at  a  minimum  from  the  on-board  recorder  data  download  port  lAW 
Section  10.4  and  optionally  by  at  least  one  COTS  media  interface.  When  accessing  COTS  media 
the  interface  file  structure  definition  defined  in  Section  10.5  shall  be  presented  at  the  on-board 
recorder  or  COTS  media  interface. 


10.4  Data  Download  and  Electrical  Interface 

The  required  recorder  download  port  interface  (see  Subsection  10.3.2)  shall  be  Fibre 
Channel,  IEEE  1394b,  Ethernet  (Subsection  10.4.3),  or  any  combination  of  the  three.  The 
physical,  signaling,  and  command  protocols  contained  in  subsections  10.4.1  and  10.4.2  are  a 
subset  of,  and  adapted  from  STANAG  4575. 

10.4.1  Eibre  Channel  Recorder  Download  Interface 

10.4. 1 . 1  Physical  and  Signaling 

The  interface  shall  comply  with  Eibre  Channel-Physical  Interfaces  and  Eibre  Channel- 
Eraming  and  Signaling  in  Section  10.9,  with  configuration  options  as  specified. 

a.  Physical  Media.  Eibre  Channel  copper  interface  will  be  utilized. 

b.  Signaling  Rate.  The  transmission  signaling  rate  shall  be  1.0625  gigabaud. 

10.4.1.2  Command  Protocol 

The  interface  shall  conform  to  the  requirements  of  the  Eibre  Channel  Private  Eoop  SCSI 
Direct  Attach  (EC-PEDA)  (American  National  Standards  Institute/International  Committee  for 
Information  Technology  Standards  TR19-1998)^  interoperability,  except  as  defined  herein. 
Table  17  of  EC-PEDA  specifies  a  control  protocol  using  a  subset  of  commands,  features,  and 
parameters  defined  for  the  Small  Computer  System  Interface  (SCSI)-3.  Table  17  of  EC-PEDA 
also  defines  the  command  feature  and  parameter  usage  categories  of  “Required,”  “Allowed,” 
“Invokable,”  and  “Prohibited”  between  the  SCSI  initiator  and  target.  These  definitions  assume 
that  the  target  is  a  magnetic  disk  drive  or  equivalent  device. 


^  International  Committee  for  Information  Technology  Standards.  “Fibre  Channel  -  Private  Loop  SCSI  Direct 
Attach  (FC-PLDA).”  INCITS  TR-19-1998.  January  1998.  Retrieved  3  June  2015.  Available  for  purchase  at 
http://www.techstreet.com/incits/searches/385689.  Replaced  by  “INCITS  Technical  Report  -  for  Information 
Technology  -  Fibre  Channel  -  Device  Attach  (FC-DA).”  INCITS  TR-36-2004.  February  2005.  Retrieved  3  June 
2015.  Available  for  purchase  at  http://www.techstreet.com/incits/searches/385707. 
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The  control  protocol  must  support  a  number  of  data  storage  media  types.  Only  the 
minimum  set  of  SCSI  commands  needed  to  download  mission  data  from  a  memory  cartridge  are 
defined  as  “Required.”  The  FC-PLDA  SCSI  commands,  features,  and  parameters  not  defined  as 
“Required”  for  this  standard  are  redefined  as  “Allowed”  so  that  they  may  be  implemented  as 
appropriate.  In  addition,  it  is  recognized  that  numerous  applications  will  be  required  to  write  to 
the  RMM  as  well.  Commands  required  to  format  and/or  write  to  an  RMM  are  defined  as 
“Recommended.”  These  commands  are  not  required  for  any  STANAG  4575  RMM 
implementation;  however,  if  the  functions  are  incorporated  into  an  application,  the  recommended 
commands  shall  be  used  to  preclude  a  proliferation  of  unique  commands.  All  other  required  FC- 
PLDA  SCSI  commands,  features,  and  parameters  not  defined  as  “Required”  or  “Recommended” 
for  STANAG  4575  are  redefined  as  “Allowed”  such  that  they  may  be  implemented  as 
appropriate.  Table  10-5  provides  the  five  required  STANAG  4575  SCSI  commands  and  two 
recommended  commands  and  their  features  and  parameter  usage  definitions.  The  NATO 
Advanced  Data  Storage  Interface  (NADSI)-compliant  recorders  may  respond  to  the  inquiry 
command  with  a  OOh  SCSI  version  code  and  the  ground/shipboard  NADSI  host  must  be  prepared 
to  accept  this  response  and  restrict  SCSI  commands  issued  to  the  STANAG  4575  mandatory  set. 


Table  10-5.  Required  and  Recommended  SCSI  Commands,  Features, 

and  Parameters 

Feature  (Command) 

Initiator 

Target* 

Notes 

Inquiry 

I 

R 

Standard  INQUIRY  data  (bytes  0-35) 

I 

R 

Enable  Vital  Product  Data=  1 

I 

R 

Enable  Vital  Product  Data  page  codes: 

0x00  (supported  vital  product  pages) 

I 

R 

0x80  (unit  serial  number  page) 

I 

R 

0x8 1  (implemented  operations  definition  page) 

I 

A 

0x82  (Basic  Character  Set  [BCS]  implemented 

I 

A 

operations  definition  page) 

0x83  (device  identification  page) 

I 

R 

Read  (10) 

I 

R 

DPO  =  0 

I 

A 

1 

DPO=  1 

I 

A 

1 

PUA  =  0 

I 

A 

2 

PUA=  1 

I 

A 

2 

RelAdr=  0 

R 

R 

RelAdr=  1 

P 

P 

3 

Read  Capacity 

I 

R 

RelAdr=  0 

R 

R 

RelAdr=  1 

P 

P 

3 

PMI  =  0 

I 

R 

PMI=  1 

I 

A 

Test  Unit  Ready 

I 

R 

Request  Sense 

I 

R 
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Write  (10) 

C 

c 

4 

DPO  =  0 

I 

A 

1 

DPO=  1 

I 

A 

1 

PUA  =  0 

I 

A 

2 

PUA=  1 

I 

A 

2 

RelAdr=  0 

c 

C 

RelAdr=  1 

p 

P 

3 

Eormat  Unit 

c 

c 

EMT  DATA  =  0 

I 

A 

m 

CMPEST  =  0 

I 

A 

DETECT  EIST  EMT=  0 

I 

A 

INTEREEAVE  =  0 

I 

A 

Notes 

1 .  The  Disable  Page  Out  (DPO)  bit  is  associated  with  a  device  data  caching  policy. 

2.  The  Force  Unit  Access  (FUA)  bit  is  associated  with  whether  the  device  may  or  may 


not  return  the  requested  read  data  from  its  local  cache. 

3.  Relative  offset  is  prohibited  since  this  requires  the  use  of  linking,  which  is  prohibited. 

4.  All  RMMs  not  supporting  recommended  or  allowed  commands  shall  respond  to  these 
commands  with  an  appropriate  error  response  and  shall  not  cease  operations. 

5.  The  FORMAT  command  shall  implement  an  initialization  of  the  target  device  such 
that  the  entire  user  memory  space  shall  be  writable.  After  performing  this  command, 
the  content  of  the  memory  may  be  indeterminate. 

*LEGEND 

P  Prohibited:  The  feature  shall  not  be  used  between  NADSTcompliant  devices. 

R  Required:  The  feature  or  parameter  value  shall  be  implemented  by  NADSTcompliant 
devices. 

C  Recommended:  The  feature  is  recommended  and  shall  be  used  for  applications 
requiring  the  functionality  of  these  commands.  The  initiator  determines  if  a 
recommended  feature/parameter  is  supported  via  a  required  discovery  process  or  a 
minimal  response  by  the  recipient. 

A  Allowed:  The  feature  or  parameter  may  be  used  between  NADSTcompliant  devices. 
The  initiator  determines  if  an  allowed  feature/parameter  is  supported  via  a  required 
discovery  process  or  a  minimal  response  by  the  recipient. 

I  Invokable:  The  feature  or  parameter  may  be  used  between  NADSTcompliant  devices. 
The  recipient  shall  support  invokable  features  or  provide  a  response  that  it  is  not 
implemented  as  defined  by  the  appropriate  standard. 


The  RMM  shall  provide  Eibre  Channel  responder  functionality  and  the  NATO  ground 
station  shall  provide  Eibre  Channel  originator  functionality.  The  RMM  shall  also  provide  SCSI 
target  functionality  and  the  NATO  ground  station  shall  provide  SCSI  initiator  functionality. 
When  an  RMM  is  powered  up  directly  through  the  NADSI  interface,  the  RMM  shall 
automatically  initialize  into  a  mode  where  the  NADSI  port  is  active  and  is  the  priority  data  and 
control  interface. 
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10.4.2  IEEE  1394b  Recorder  Interface 

The  IEEE  1394b  recorder  download  interface  shall  use  the  same  mechanisms  as  Section 
10.9  where  applicable. 

10.4.2.1  Physical  and  Signaling 

The  interface  shall  allow  control  of  vendor-specific  recorder  devices.  The  command 
protocol  shall  be  lAW  Subsection  10.4.1.2  and  Table  10-5. 


10.4.2.2  Recorder  Communication 

The  fundamental  method  of  communicating  shall  be  lAW  the  IEEE  1394b  protocol.^ 
Packets  sent  and  received  shall  be  asynchronous  transmissions.  The  IEEE  1394b  packets  shall 
encapsulate  Serial  Bus  Protocol  (SBP)-2  formatted  packets  for  the  transport  of  commands  and 
data.  Recorder  devices  are  to  use  SCSI  command  set(s)  and  therefore  SCSI  commands  and 
status  shall  be  encapsulated  in  SBP-2  operation  request  blocks  (ORBs). 


NOTE 


The  SBP-2  provides  for  the  transport  of  6-,  10-, 
and  12-byte  SCSI  command  descriptor  blocks 
(CDBs)  within  a  command  ORB. 


10.4.3  Ethernet  Recorder  Interface 

Eor  a  recorder  containing  an  Ethernet  interface  for  the  data  download  port,  ETP  and/or 
T--/ — T-/  iSCSI  protocols  shall  be  used.  If  ETP  will  be  implemented  the  requirements  set  forth  in 

Subsection  10.9.3.4  shall  be  followed.  If  the  iSCSI  protocol  is  to  be  implemented  then  the  host 
ground  system  will  act  as  the  initiator  and  the  recorder  will  act  as  the  target. 

The  recorder  Ethernet  interface  shall  use  the  Telnet  protocol.  As  a  minimum 
requirement,  the  Telnet  interface  will  implement  Internet  Engineering  Task  Eorce  (lETE) 
Request  for  Comment  (REC)  854^,  REC  855^,  and  REC  1184.^  The  protocol  will  support 
Chapter  6  CCM  (Subsection  10.7.8)  over  a  TCP/IP  connection  on  port  #  10610.  The  Telnet 
interface  must  respond  with  a  when  a  connection  is  made. 

10.4.3. 1  Target  Eogical  Unit  Number  Assignments 

The  following  iSCSI  target  logical  unit  number  (EUN)  assignments  shall  be  used. 

a.  The  EUN  0  or  32  shall  be  used  for  recorder  data  download  via  Section  10.5  interface. 

b.  The  EUN  1  or  33  shall  be  used  for  recorder  CCM  lAW  the  requirements  for  the  optional 
ISCSI  recorder  control  defined  within  Section  10.7. 


^  Institute  of  Electrical  and  Electronics  Engineers.  IEEE  Standard  for  a  High  Performance  Serial  Bus:  Amendment 
2.  IEEE  13946-2002.  New  York:  Institute  of  Electrical  and  Electronics  Engineers,  2002. 

Internet  Engineering  Task  Eorce.  “Telnet  Protocol  Specification.”  REC  854.  May  1983.  Updated  by  REC  5198. 
Retrieved  3  June  2015.  Available  at  http://tools.ietf.org/html/rfc854. 

^  Internet  Engineering  Task  Eorce.  “Telnet  Option  Specifications.”  REC  855.  May  1983.  May  be  superseded  or 
amended  by  update.  Retrieved  3  June  2015.  Available  at  http://datatracker.ietf  org/doc/rfc855/. 

®  Internet  Engineering  Task  Eorce.  “Telnet  Line  mode  Option.”  D.  Borman,  ed.  REC  1184.  October  1990.  Maybe 
superseded  or  amended  by  update.  Retrieved  3  June  2015.  Available  at  http://datatracker.ietf.org/doc/rfcll84/. 
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10.4.3.2  Naming  and  Addressing 

The  host  ground  system  (initiator)  and  recorder  (target)  devices  on  the  network  must  be 
named  with  a  unique  identifier  and  assigned  an  address  for  access.  The  iSCSI  initiators  and 
target  nodes  can  either  use  an  iSCSI  qualified  name  (IQN)  or  an  enterprise-unique  identifier 
(EUI).  Both  types  of  identifiers  confer  names  that  are  permanent  and  globally  unique. 

Each  node  has  an  address  consisting  of  the  IP  address,  the  TCP  port  number,  and  either 
the  IQN  or  EUI.  The  IP  address  can  be  assigned  by  using  the  same  methods  commonly 
employed  on  networks,  such  as  Dynamic  Host  Control  Protocol  (DHCP)  or  manual 
configuration. 

10.4.3.3  Physical  and  Signaling 

The  interface  shall  allow  control  of  vendor-unique  recorder  devices.  The  command 
protocol  shall  be  lAW  Subsection  10.4.1.2  and  Table  10-5. 

10.4.3.4  Recorder  Communication 

The  fundamental  method  of  communicating  shall  be  lAW  the  iSCSI  protocol.  Packets 
sent  and  received  shall  be  asynchronous  transmissions. 

10.5  Interface  File  Structure  Definitions 

The  definitions  in  this  paragraph  are  a  subset  of,  and  were  adapted  from  Section  3  of 
STANAG  4575.  This  file  structure  was  selected  to  facilitate  host  computing  platform 
independence  and  commonality.  By  incorporating  an  independent  file  structure,  backward  and 
forward  compatibility  is  ensured  for  the  life  of  the  standard. 


NOT^^ 

This  section  duplicates  text  from  STANAG  4575.  Any  definition  in  this 
standard  that  varies  from  the  STANAG  4575  text  is  noted  in  a  NOTE  box. 

The  text  in  a  NOTE  box  takes  precedence  over  the  text  from  STANAG  4575. 

NOT^^ 

This  file  structure  definition  does  not  define  how  data  is  physically  stored  on 
the  recorder  media  but  provides  a  standardized  method  for  access  of  the 
stored  data  at  the  interface.  Data  can  be  organized  in  any  way  appropriate  to 
the  media,  including  multiple  directories,  as  long  as  the  file  structure  lAW 
Section  10.5  is  maintained  or  seen  at  the  interface  (Section  10.4). 

10.5.1  Data  Organization 

A  data  recording  can  contain  a  single  file,  which  is  composed  of  one  or  more  types  of 
packetized  data,  or  multiple  files,  in  which  one  or  more  types  of  data  are  recorded 
simultaneously  in  separate  files.  Eor  a  recording  file  to  be  lAW  this  standard,  it  must  contain  as 
a  minimum  the  following. 

a.  Computer-Generated  Packet(s),  Eormat  1  setup  record  lAW  Chapter  1 1  Subsection 
1 1 .2.7.2  as  the  first  packets  in  the  recording 

b.  Time  data  packet(s)  lAW  Chapter  1 1  Subsection  1 1.2.3  as  the  first  dynamic  packet  after 
the  computer-generated  packet,  setup  record 

c.  One  or  more  data  format  packets  lAW  Section  10.6 
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Multiple  recordings  may  reside  on  the  media,  and  each  recording  may  contain  one  or 
more  compliant  files. 

The  data  hierarchy  used  to  define  the  data  stored  according  to  this  standard  shall  have  the 
following  structural  relationships  (highest  to  lowest).  See  Figure  10-9. 


Directory 


Logical  Block  Address  0  [N, 


Directory 

Block 


Logical  Block  Address  1 


Logical  Block  Address  n 
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Variable  Length  as 
defined  in  "#  of  File 
Entries" 

Padding  to  next 
block  size  boundary 
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\ 


Revision  Number 


Shutdown 
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►  Fixed  64  Bytes 


File  Entry  R 


File  Entry  R  ♦  1 
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File  Entry  R  +  n 
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File  Name 


File  Start  Address 


File  Block  Count 
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Time  Type 
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File  Close  Time 


Data  File 


►  Fixed  1 1 2  Bytes 


Directory 

Block 

File 

Entry 


Figure  10-9.  Directory  Structure 


a.  Directory.  One  or  more  directory  blocks  of  data  comprising  a  list  of  all  data  files  located 
under  the  guidance  of  this  standard.  Also  contains  supporting  data  that  may  be  of  interest 
to  those  manipulating  the  data  files.  The  list  of  files  is  made  up  from  “File  Entries.”  The 
directory  shall  always  start  at  logical  address  zero  of  each  directory  block. 

b.  Directory  Block.  A  memory  block  containing  file  entries  and  other  metadata. 

c.  Directory  Block  File  Entry.  A  fixed- length  data  structure  used  to  describe  files.  It 
contains  the  name,  the  starting  address,  the  number  of  blocks  of  data  assigned  to  the  data 
file,  the  total  number  of  bytes  contained  in  the  file,  and  the  file’s  creation  date  and  time. 

It  also  contains  a  reserved  field  for  future  growth  and  file  close  time. 

d.  Data  Eiles.  Data  files  are  comprised  of  user  data,  presented  at  the  interface  in 
monotonically  increasing  contiguous  logical  addresses  per  file.  Thus  if  a  file  starts  at 
logical  address  X,  the  next  location  containing  file  data  must  be  at  the  next  logical 
address,  X-f1,  and  the  next  location  after  that  must  be  at  the  next  logical  address,  X-f2, 
etc. 
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10.5.2  Directory  Definition 

The  name  and  location  information  for  all  files  recorded  in  a  directory  is  illustrated  in 
Figure  10-9.  The  directory  is  composed  of  one  or  more  directory  blocks  as  shown  in  Figure 
10-10.  At  least  one  directory  block  is  required  and  it  must  be  located  at  SCSI  logical  block 
address  1.  Logical  block  address  0  is  reserved. 


Figure  10-10.  Directory  Block 


a.  Directory  Fixed  Fields.  The  fixed  fields  within  a  directory  block  are  used  to  name  the 
volume  of  data,  identify  the  number  of  entries,  and  provide  pointers  to  other  addresses 
that  contain  additional  directory  blocks.  Forward  and  backward  links  to  the  next  address 
for  the  next  directory  block  (if  any)  or  the  preceding  directory  block  (if  any)  allow  for 
directory  expansion  beyond  a  single  block.  This  does  not  limit  the  placement  of  directory 
information. 

b.  Block  Size.  The  media  types  used  to  implement  this  standard  have  varying  block  lengths. 
Some  will  have  blocks  as  small  as  512  bytes;  others  may  have  blocks  as  large  as  64  kb  or 
larger.  The  block  size  used  by  a  given  media  can  be  determined  via  the  SCSI  Read 
Capacity  command  (not  defined  here). 

c.  Directory  to  Data  File  Link.  Each  data  file  on  the  media  has  a  directory  entry  within  a 
directory  block  that  describes  the  file,  as  shown  in  Table  10-6.  The  directory  entry  for  a 
data  file,  as  shown  in  Table  10-7,  contains  a  link  to  the  starting  location  of  the  data 
contained  in  each  file  and  the  total  number  of  blocks  assigned  for  the  storage  of  data. 

This  standard  does  not  define  the  meaning  of  the  data  recorded  within  these  data  file 
blocks. 


Table  10-6.  Directory  Block  Format 

Field  Name 

Bytes 

Description 

Data  Type 

Magic  Number 

8 

An  identifier  for  a  directory  block.  This  identifier 
supports  discovery  of  lost  directory  entries  and 
directory  reconstruction  after  a  fault.  The  value  is 

BCS  “FORTYtwo”  (0x464F52545974776F) 

BCS 

Revision 

Number 

1 

Revision  number  of  the  standard  compiled  by  the 
recording  system. 

0x01  =  RCC  106-03  through  RCC  106-05 

OxOF  =  RCC  106-07  or  later 

Unsigned 

Binary 
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Table  10-6.  Directory  Block  Format 

Field  Name 

Bytes 

Description 

Data  Type 

Shutdown 

1 

Flag,  if  cleared  to  a  0x00,  indicates  that  the  volume 
was  not  properly  dismounted,  and  if  seen  on  power-up 
is  an  indication  that  the  directory  chain  may  be  faulty. 

If  set  =  OxFF,  then  the  file  system  properly  shutdown. 
This  field  is  only  valid  in  the  first  directory  located  in 
logical  block  1;  other  directory  blocks  set  to  OxFF. 

Unsigned 

Binary 

Number  of  File 
Entries 

2 

Defines  the  number  of  file  entries  that  follow  in  this 
block. 

Unsigned 

Binary 

Block  Size 

4 

Bvtes  per  block  size  referenced  in  FileBlkCnt  in  Table 
10-7. 

Unsigned 

Binary 

VolName 

32 

Volume  name,  see  character  set  for  restrictions.  (Fill 
any  unused  VolName  byte  positions  with  0x00.) 

BCS 

Forward  Link 

8 

Block  address  of  the  next  block  containing  directory 
information.  Set  equal  to  address  of  this  block  if  this 
is  the  end  of  the  chain. 

Unsigned 

Binary 

Reverse  Link 

8 

Block  address  of  the  directory  block  pointing  to  this 
block.  Set  equal  to  this  block  address  if  this  is  the 
start  of  the  chain. 

Unsigned 

Binary 

(n  File  Entries) 

112  *n 

One  entry  for  each  file  specified  in  “Number  of  File 
Entries.”  The  maximum  value  of  n  is  dependent  upon 
media  block  size. 

See  Table 
10-7 

Unused 

Varies 
with  n  & 
block 
size 

It  is  possible  for  bytes  to  remain  between  the  last  byte 
of  the  last-used  file  entry  and  the  end  of  the  directory 
block.  These  bytes  are  defined  as  unused  and  should 
be  filled  with  OxFF. 

Unsigned 

Binary 

Note:  64  bytes  in  fixed  fielc 

s. 

Table  10-7.  Data  File  Entry  Format 

Field  Name 

Bytes 

Description 

Data 

Type 

Name 

56 

File  name  (see  character  set  for  restrictions).  Fill  any 
unused  File  Name  byte  positions  with  0x00. 

BCS 

FileStartAdd 

8 

Zero-based  address  of  the  first  block  reserved  for  data 
associated  with  this  file.  Fill  with  OxFF  for  unused 
directory  entries. 

Unsigned 

Binary 

FileBlkCnt 

8 

One-based  number  that  is  the  count  of  consecutive 
address  blocks  reserved  for  data  for  this  file  including  the 
block  pointed  to  by  the  FileStartAdd  field. 

Unsigned 

Binary 

FileSize 

8 

The  actual  number  of  bytes  contained  in  this  file.  This 
file  size  will  be  equal  to  or  less  than  the  FileBlkCnt 
multiplied  by  the  block  size.  This  is  an  optional  entry 
and  will  be  filled  with  OxFF  if  not  used. 

Unsigned 

Binary 
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Table  10-7.  Data  File  Entry  Format 

Field  Name 

Bytes 

Description 

Data 

Type 

File  Create  Date 

8 

DDMMYYYY  BCS  character  values,  with  no  embedded 
spaces  or  other  formatting  characters,  representing  the 
numeric  date  on  which  the  file  was  created  (e.g.,  BCS 
codes  for  the  decimal  digits  02092000 
0x3032303932303030  represents  2  September  2000). 

Fill  with  0x2D  if  a  value  for  the  field  is  not  available,  or 
for  portions  of  the  field  where  data  is  not  available. 

BCS 

File  Create 

Time 

8 

HHMMSSss  character  values,  with  no  embedded  spaces 
or  other  formatting  characters,  representing  the  numeric 
time  at  which  the  file  was  created.  HH  is  the  number  of 
hours  in  a  24-hour-based  day,  MM  is  the  number  of 
minutes  after  the  hour,  SS  is  the  number  of  seconds  after 
the  minute,  and  ss  is  the  hundredths  of  seconds  after  the 
second.  Fill  with  0x2D  if  a  value  for  the  field  is  not 
available,  or  for  portions  of  the  field  where  data  is  not 
available  (e.g.,  “ss”  is  not  available). 

BCS 

Time  Type 

1 

A  numeric  code  that  qualifies  the  time  and  date  values 
recorded  in  the  “Create  Date”  and  “Create  Time”  and 
“Close  Time”  fields. 

0x0  =  Universal  Coordinated  Time  (Zulu) 

0x1  =  System  Time 

0x2  -  OxFE  =  Reserved 

OxFF  =  Time  data  packet 

Unsigned 

Binary 

Reserved 

7 

Bytes  in  this  region  are  reserved  for  future  growth.  Fill 
with  OxFF. 

Unsigned 

Binary 

File  Close  Time 

8 

HHMMSSss  character  values,  with  no  embedded  spaces 
or  other  formatting  characters,  representing  the  numeric 
time  at  which  the  file  was  closed.  HH  is  the  number  of 
hours  in  a  24-hour-based  day,  MM  is  the  number  of 
minutes  after  the  hour,  SS  is  the  number  of  seconds  after 
the  minute,  and  ss  is  the  hundredths  of  seconds  after  the 
second.  Fill  with  0x2D  if  a  value  for  the  field  is  not 
available,  or  for  portions  of  the  field  where  data  is  not 
available  (e.g.,  “ss”  is  not  available). 

BCS 

Note:  112  bytes  in  fixed  : 

lelds. 

d.  File  Entry  Name.  Each  file  entry  in  a  directory  shall  have  a  unique  name  (see  Subsection 
10.5.3.4).  Default  file  name  is  a  BCS  numeric  value  incrementally  increasing,  starting  at 
value  “1.” 

e.  File  Entry  Singularity.  Multiple  file  entries  are  not  permitted  to  refer  to  the  same  regions 
of  memory,  partially  or  completely. 
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f.  Directory  Entries  and  Fields.  Directory  block  fields  and  entries  shall  be  logically 
contiguous. 


g.  Directory  and  Memory  Region  Relationships.  File  entries  shall  be  entered  sequentially 
into  a  directory  block  as  files  are  recorded,  starting  with  file  entry  #1  in  the  primary 
directory  block  (logical  address  1).  All  file  entry  positions  in  the  primary  directory  block 
shall  be  filled  before  the  first  secondary  directory  block  is  used,  and  so  on;  howeyer, 
there  is  no  a  priori  relationship  between  the  memory  region  associated  with  a  file  entry 
and  the  place-order  of  the  file  entry  within  the  oyerall  directory.  For  example,  the  yery 
first  file  entry  could  refer  to  the  yery  last  logical  address  region  of  memory,  the  second 
file  entry  could  refer  to  the  beginning  logical  address  of  memory,  and  so  on.  Similarly, 
there  is  no  presumed  temporal  ordering  of  file  entries;  the  yery  last  entry  to  be  inserted 
could  be  inserted  in  such  a  fashion  so  as  to  be  the  first  entry  encountered  when  trayersing 
the  directory  chain  of  blocks. 

h.  Empty  Memory  Reads.  Reads  of  regions  of  memory  not  containing  directory  blocks  or 
data  file  blocks  may  return  unpredictable  data  yalues  or  result  in  other  error  conditions. 


Contiguous  Directory  Entries.  Eile  entries  and  all  fields  in  a  directory  block  are 
contiguous. 


NOTE 


Deleted  files  are  not  applicable  to  Chapter  10 
as  there  are  no  recorder  commands  that  allow 
or  proyide  file  deletion. 


j.  Deleted  Eiles.  In  some  applications,  preyiously  recorded  files  may  be  deleted  in  order  to 
recoyer  media  space  for  new  recordings.  Deleted  files  shall  be  denoted  by  marking  the 
corresponding  file  entry’s  file  block  count  field  with  0x00  indicating  “unused.”  If  the  file 
block  count  has  been  set  to  0x00,  then  other  fields  in  that  file  entry  are  no  longer 
meaningful. 

k.  Reseryed  Eield.  Reseryed  fields  shall  not  be  used  in  Chapter  10  implementations  and 
shall  be  filled  with  OxEE.  Reseryed  fields  are  intended  for  future  Chapter  10  use. 

l.  Number  of  Eile  Entries.  The  numerical  yalue  placed  in  the  “Number  of  Eile  Entries” 
field  of  a  directory  block  shall  equal  the  number  of  actiye  file  entries  plus  any  file  entries 
marked  as  deleted  files  within  that  directory  block. 

10.5.3  Data  Definitions 


10.5.3.1  Directory  B  y te  Order 

The  directory  structures  described  in  Section  10.5  of  this  standard  are  defined  to  haye  the 
following  bit  and  byte  orientation.  The  most  significant  byte  of  any  multi-byte  structure  is  byte 
0.  The  msb  of  each  byte  is  bit  0.  This  ordering  is  commonly  referred  to  as  “Big  Endian.” 

10.5.3.2  Data  Eormat  Byte  Order 

The  data  format  structures  (Packet  Header,  etc.)  are  defined  by  Chapter  1 1  to  haye  the 
following  bit  and  byte  orientation.  The  least  significant  byte  shall  be  transmitted  first,  the  Isb  of 
each  byte  shall  be  transmitted  first,  and  data  is  read  from  the  lowest  logical  address  first.  This 
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ordering  is  commonly  referred  to  as  “Little  Endian.”  The  packet  data  remains  in  its  native  byte 
order  format. 

10.5.3.3  Character  Set 

The  character  set  for  all  character  fields  is  based  on  ISO/IEC  10646:2012.’  The  NATO 
Imagery  Interoperability  Architecture  limits  characters  to  a  subset  rather  than  allowing  all 
characters.  The  subset  will  be  single  octets,  known  as  the  BCS. 

10.5.3.4  Naming  Restrictions 

The  following  rules  shall  be  applied  when  forming  names  in  order  to  assure  the  highest 
degree  of  interchange  among  other  operating  systems. 

a.  Characters.  Characters  from  the  first  127  common  BCS  characters  (0x00  through  0x7E) 
may  be  used  in  names  except  for  specific  prohibited  characters. 

(1)  Any  BCS  character  code  value  smaller  than  0x20  is  prohibited,  except  where  the 
0x00  is  used  to  terminate  the  name. 

(2)  The  other  prohibited  characters  with  their  hexadecimal  representation  are  defined  in 
Table  10-8. 


Table  10-8.  Prohibited  Characters  (Hexadecimal  Representation) 

Forbidden 

Hexadecimal 

Forbidden  Characters 

Hexadecimal 

Characters  in  Names 

Value 

in  Names 

Value 

0x22 

= 

0x3D 

i 

0x27 

> 

0x3E 

* 

0x2A 

? 

0x3F 

1 

0x2E 

\ 

0x5C 

0x3A 

] 

0x5D 

? 

0x3B 

[ 

0x5B 

< 

0x3C 

1 

0x7C 

b.  Names.  Names  used  for  this  interface  will  observe  the  following  rules. 

(1)  Upper  and  lowercase  characters  are  considered  to  be  different  within  file  names. 

(2)  Eeading  and  trailing  spaces  are  not  permitted. 

(3)  Eeading  periods  are  not  permitted. 

(4)  Names  shall  fill  their  field  starting  with  byte  0  per  Subsection  10.5.3.1  and  be 
terminated  with  a  0x00.  Unused  name  characters  shall  be  filled  with  0x00.  Names 
may  utilize  the  full  length  of  the  field,  in  which  case  the  terminating  0x00  must  be 
omitted.  Examples  of  host-provided  and  default  file  names  are  shown  in  Eigure 
10-11. 


^  International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
Technology —Universal  Coded  Character  Set  (UCS).  ISO/IEC  10646:2012.  May  2012.  May  be  superseded  by 
update.  Retrieved  3  June  2015.  Available  at  http :// standards . iso.org/ittf/PubliclvAvailableStandards/index. html . 
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File  Name  Byte  Address  /  l 

°  1  2  3  4  5  6  7  8  9  ^  ^  ^  ;  M/ 

Host  Provided  File  Name  Example  /  / 

5  5  5  5  5  5 

0  1  2  3  4  5 

R 

E 

C 

o 

R 

D 

I 

N 

G 

1 

s 

E 

N 

S 

O 

R 

2 

OX 

00 

OX 

00 

OX 

00 

OX 

00 

OX 

00 

OX 

00 

OX 

00 

Default  File  Name  Example  /  / 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

oflo 

0 

0 

0 

0 

0 

1 

Figure  10-11.  File  Name  Examples 


10.6  Data  Format  Definition 

10.6.1  IRIG  106  Chapter  11 

Data  shall  be  formatted  lAW  Chapter  1 1 . 

Single  or  multiple  channel  recordings  will  always  conform  to  the  structure  outlined  in 
Figure  10-12;  note  that  the  details  of  the  packet  structure  are  defined  by  Chapter  1 1  and  are 
included  here  for  information  only. 
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Single  or  Multiple  Channel  Recording.  Will 
always  conform  to  the  following: 


Must  be  first  packet  m  recording 


Must 


be  first  dynamic  packet  In  recording 


Each  packet  must  be  generated  equal  to  or  less  than 
too  milliseconds  All  packets  generated  must  be  committed 
to  the  stream  equal  to  or  less  than  1000  milliseconds 


Time  data  packet  frequency  is  a  minimum  of  1  Hz 


Packet 

Header 


Optional 

Packet 

Secondary 

Header 


Packet  Body 


Packet  Trailer 


Computer  Generated  Data  Packet, 
Format  1  Setup  Records 


s 


Time  Data  Packet 


Data  Packet 


Data  Packet 


Data  Packet 


Time  Data  Packet 


Figure  10-12.  Data  Recording  Structure 
a.  Certain  packets  are  required  by  this  standard,  and  areas  shown  in  Table  10-9. 
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Table  10-9.  Required  Packets  and  Locations 

Packet  Type 

Required 

Required  Packet  Location 

Computer-Generated  Data 
Packet,  Format  1  Setup  Record 

Yes 

First  packets  in  recording.  A  single 
setup  record  may  span  across  multiple 
Computer-Generated  Data  Packet, 

Format  1  setup  records. 

Time  Data  Packet 

Yes 

First  dynamic  data  packet  following 
setup  record  packet(s).  Refer  to  the  time 
data  packet  description  for  packet  rate. 

All  other  data  type  packets 
with  the  exception  of 
Computer-Generated  Data 
Packet,  Format  1  setup  record, 
time  data  packets,  and 
Computer-Generated  Data 
Packet,  Format  3  recording 
index  (root  index) 

No 

After  first  time  data  packet  and  before 
the  last  Computer-Generated  Data 

Packet  Format  3,  recording  index  (root 
index)  if  enabled. 

Computer-Generated  Data 
Packet,  Format  3  recording 
index  (root  index) 

Yes,  if  recording 
events  are  enabled. 
No,  if  recording 
events  are  disabled. 

If  recording  index  packets  are  enabled, 
root  index  packet  type  will  be  the  last 
packet  in  a  recording. 

b.  With  the  exception  of  computer-generated  packets,  all  other  packet  generation  times  shall 
be  equal  to  or  less  than  100  milliseconds  (ms)  as  measured  by  the  10-megahertz  (MHz) 
relative  time  counter  (RTC)  whenever  data  is  available.  This  requirement  ensures  that  a 
packet  shall  contain  equal  to  or  less  than  100  ms  worth  of  data,  and  that  a  packet 
containing  any  data  must  be  generated  equal  to  or  less  than  100  ms  from  the  time  the  first 
data  was  placed  in  the  packet.  This  strategy  will  assure  packet  granularity  and  save 
bandwidth  by  not  forcing  or  marking  empty/idle  packets. 

c.  With  the  exception  of  computer-generated  data  packets,  all  other  packets  shall  have  a 
stream  commit  time  equal  to  or  less  than  1000  ms  as  measured  by  the  10-MHz  RTC 
contained  in  the  packet  header. 

10.6.2  Time  Data  Packets 

Time  is  treated  like  another  data  channel.  If  a  time  source  other  than  None  is  used  (see 
Chapter  1 1 ,  Section  1 1.2.3),  the  time  packet  shall  be  generated  at  a  minimum  frequency  of  1 
hertz. 

A  time  data  packet  shall  be  the  first  dynamic  data  packet  at  the  start  of  each  recording. 
Only  static  Computer-Generated  Data,  Format  1  packets  may  precede  the  first  time  data  packet 
in  the  recording.  If  the  time  data  packet  source  is  “None”,  at  least  one  time  data  packet  is 
required  lAW  the  previous  sentence. 
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10.7  Recorder  Control 

The  recorder  shall  be  controlled  by  either  discrete  control/status  lines  and/or  serial 
communication  ports.  The  serial  interface  shall  consist  of  both  RS-232  and  RS-422  full  duplex 
serial  communications. 

10.7.1  Recorder  Control  and  Status 

The  RS-232  and  RS-422  serial  communication  ports  shall  be  functional  simultaneously 
without  requiring  selection  of  either  port.  Status  requested  by  either  port  shall  be  returned  on 
both  ports.  Note  that  unexpected  results  may  occur  if  commands  are  issued  on  both  ports 
simultaneously. 

10.7. 1 . 1  Mandatory  Recorder  Control 

The  recorder  shall  provide  control  by  either  serial  communications  ports  supporting  a 
command  line  interface  (CLI)  lAW  Chapter  6  Subsection  6.2  and/or  discrete  control/status  lines 
lAW  Subsection  6.4. 

10.7. 1 .2  Optional  Recorder  Control 

The  recorder  may  be  controlled  over  the  Fibre  Channel,  IEEE  1394b,  or  Ethernet 
recorder  download  interface  ports  from  Section  10.4.  These  interfaces  shall  support 
communications  using  SCSI  (Eibre  Channel)  lAW  Subsection  10.4.1,  SCSI  over  SBP-2  (IEEE 
1394b)  lAW  Subsection  10.4.2,  or  iSCSI  (Ethernet)  lAW  Subsection  10.4.3.  Recorder  login  and 
Chapter  6  CCM  shall  be  transmitted  and  received  using  the  SCSI  ORB  structures  lAW 
subsections  10.9.3  (as  required  for  IEEE  1394b),  10.9.4,  and  10.9.12. 

10.7. 1 .3  Optional  Telnet  Control 

The  recorder  may  be  controlled  over  Ethernet/Telnet  utilizing  CEI  as  defined  in  Chapter 

6. 

10.7.2  Communication  Ports 

The  RS-232  and  RS-422  serial  communication  ports  shall  be  functional  simultaneously 
without  requiring  selection  of  either  port.  Status  requested  by  either  port  shall  be  returned  on 
both  ports.  Note  that  unexpected  results  may  occur  if  commands  are  issued  on  both  ports 
simultaneously. 

10.7.3  RS-232/422  Port 

An  RS-232/422  port  shall  be  available  at  the  download  port. 

10.7.4  Commands 

Commands  received  through  the  serial  communication  ports  shall  not  override  hardwire 
discrete  controls. 

10.7.5  Status  Requests 

Status  requests  received  through  the  serial  communication  ports  shall  not  interfere  with 
hardwire  controls. 

10.7.6  Serial  Status 

Serial  status  shall  be  provided  on  either  serial  status  request  or  discrete  activation. 
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10.7.7  Default  Interface 

Default  interface  with  user  equipment  shall  utilize  the  following  ASCII  serial 
communication  protocol. 

38400  baud 

One  start  bit 

8 -bit  data 

No  parity 

One  stop  bit 

Serial  Commands 

The  serial  ports  shall  implement  a  CLI  as  described  in  Chapter  6. 

Required  Discrete  Control  Functions 

Discrete  control  functions  and  associated  status  are  described  in  Chapter  6,  Subsection 

Declassification 

As  of  IRIG  106-17  this  section  was  moved  to  Appendix  10-B. 

Host  Platform  Interface  to  Recorder  Media 

Two  interfaces,  IEEE  1394b  and  IEEE  802.3  “Ethernet”,  are  defined  to  provide  a 
communication  path  to  read  and/or  download  data  from  an  RMM  and  to  write  an  RSCE  to  an 
RMM.  The  selection  of  these  protocols  was  adopted  to  facilitate  a  common  interface  between 
the  media  and  the  computing  platform.  It  is  anticipated  that  any  particular  RMM  will  support 
only  one  of  the  two  host  platform  interfaces. 


NOTE^ 

This  definition  does  not  mandate  the 

A 

interface  between  the  recorder  and  media. 

10.9.1  Media  Time  Synchronization 

In  order  to  allow  recorders  to  be  synchronized  to  the  same  time  without  requiring 
platform  modification  or  an  external  time  source  being  provided  to  the  recorder,  the  removable 
media  cartridges  can  optionally  maintain  time,  allowing  for  time  initialization  of  the  recorder. 
Removable  media  cartridges  can  optionally  provide  a  battery  back-up  real-time  clock  device. 
Initialization  of  time  can  optionally  be  accomplished  via  the  host  platform  interface. 

10.9.2  Physical  and  Signaling 

Each  host  platform  interface  has  distinct  requirements  for  the  physical  interface  and 
signaling  levels. 

10.9.2.1  IEEE  1394b  Interface 

The  IEEE  1394b  host  platform  interface  shall  provide  data  communications  and  power 
using  the  same  connector  lAW  IEEE  1394b. 


a. 

b. 

c. 

d. 

e. 


10.7.8 


10.9 
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10.9.2.2  Ethernet  Interface 

The  Ethernet  host  platform  interface  shall  be  lAW  the  IEEE  802.3  standards.  Only  a 
subset  of  the  physical  interfaces  defined  by  IEEE  802.3  shall  be  employed.  A  power  input 
accepting  8-30  volts  direct  current  and  drawing  a  current  of  not  to  exceed  5  amps  shall  be 
provided.  Additionally,  Power  Over  Ethernet  (PoE)  lAW  IEEE  802.3at-2009^  may  be  used  to 
deliver  power  to  the  RMM. 

a.  100Base-TX.  Eor  data  rates  of  up  to  100  megabits  per  second  (Mbps),  100Base-TX 
signaling  lAW  IEEE  802.3  shall  be  employed. 

b.  lOOOBase-T.  Eor  data  rates  in  excess  of  100  Mbps  but  less  than  1000  Mbps,  lOOOBase-T 
with  auto  negotiation  to  lower  speeds  as  defined  in  Paragraph  a  above  shall  be  employed 
lAW  IEEE  802.3. 

c.  lOG-Base-T.  Eor  data  rates  in  excess  of  1000  Mbps,  lOGBase-T  with  auto  negotiation  to 
lower  speeds  as  defined  in  item  b  above  shall  be  employed  lAW  IEEE  802.3. 

10.9.3  Removable  Media  Communication 

Eogically,  each  compliant  RMM  shall  contain  two  distinct  functional  entities  as  per 
Eigure  10-13.  The  mechanisms  used  to  communicate  with  the  two  functional  entities  vary 
according  to  the  host  platform  interface  type. 


Eigure  10-13.  Removable  Media 


10.9.3.1  IEEE  1394b  Host  Platform  Interface 

The  fundamental  method  of  communicating  shall  be  lAW  the  IEEE  1394b  protocol. 
Packets  sent  and  received  shall  be  asynchronous  transmissions.  The  IEEE  1394b  packets  shall 


o 

Institute  of  Electrical  and  Electronics  Engineers.  IEEE  Standard  for  Information  technology  - 
Telecommunications  and  information  exchange  between  systems. .  .Amendment  3:  Data  Terminal  Equipment  (DTE) 
Power  via  the  Media  Dependent  Interface  (MDI)  Enhancements.  IEEE  802.3at-2009.  October  2009.  Superseded 
by  update.  Retrieved  3  June  2015.  Available  with  registration  at  http://standards.ieee.org/findstds/standard/802.3at- 


2009.html. 
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encapsulate  SBP-2-formatted  packets  for  the  transport  of  commands  and  data.  Removable  media 
devices  are  to  use  SCSI  command  set(s)  and  therefore  SCSI  commands  and  status  shall  be 
encapsulated  in  SBP-2  ORBs. 


NOTE/^ 

SBP-2  provides  for  the  transport  of  6-,  10-, 

and  12-byte  SCSI  CDBs  within  a  eommand 

r 

ORB. 

10.9.3.2  IEEE  802.3  Ethernet  Host  Platform  Interface 

The  fundamental  method  of  communicating  shall  be  lAW  the  IPv4  protocol  defined  by 
lETE  RPC  791^and  subsequent  related  documents. 

a.  MTU  (Prame  size).  Pollowing  power  on  or  reset,  the  RMM  shall  select  an  MTU  of  1500 
bytes. 

b.  RMM  IP  Addressing.  Each  RMM  should  attempt  to  obtain  an  IP  addressing  using  DHCP 
lAW  lETP  RPC  213C°  with  the  options  as  described  below.  In  the  event  no  IP  address 
can  be  obtained  via  DHCP,  the  RMM  shall  use  a  static  IP.  By  default,  the  static  IP 
address  shall  be  set  to  10.9.3.2,  with  a  net  mask  of  255.0.0.0,  and  a  default  gateway  of 
10.9.3.1.  The  default  static  IP  can  be  changed  by  sending  a  .RMMIP  IP  address 
command  as  defined  in  Chapter  6  Subsection  6. 5. 6. 3. 

When  using  DHCP  to  obtain  an  IP  address,  the  RMM  shall  send  a  DHCP  vendor  class 
identifier  option  (code  60)  lAW  lETP  RPC  2131  to  the  server,  and  the  first  10  characters 
of  the  data  string  sent  with  the  vendor  class  identifier  option  shall  be  the  text 
“RMM:CH10:”,  optionally  followed  by  information  further  identifying  the  type  of  RMM. 

c.  RMM  Discovery.  The  RMM  shall  implement  a  service  location  protocol  (SEP)  service 
agent  lAW  lETP  RPC  2608  *  *  and  Table  10-10.  The  ground  station  may  implement  an 
SEP  user  agent  or  any  other  suitable  method  (e.g.,  tight  integration  with  the  DHCP 
server)  to  determine  the  IP  address  assigned  to  an  RMM.  The  RMM  may  provide  a  set  of 
service  attributes  lAW  Table  10- 10.  The  SEP  authentication  blocks  shall  not  be  required. 


Table  10-10.  Ethernet  Service  Location  Protocol  Characteristics 

Characteristic 

Provision 

Type 

Value 

Service  Name 

Required 

String 

service:  RMM  TRIG  106: 

Service  Eocation 

Required 

String 

//nnn.nnn.nnn.nnn[:pppp]representing  the  IP 
address  of  the  RMM  and  optionally  the  port 
number  (pppp)  on  which  the  Telnet  service  will 
respond  if  not  port  923  (see  Subsection  10.9.4.2) 

®  Internet  Engineering  Task  Force.  “Internet  Protocol.”  RFC  791.  September  1981.  Updated  by  RFC  1349,  RFC 
6864,  and  RFC  2474.  Retrieved  3  June  2015.  Available  at  http://datatracker.ietf.org/doc/rfc791/. 

Internet  Engineering  Task  Force.  “Dynamic  Host  Configuration  Protocol.”  RFC  2131.  March  1997.  Updated  by 
RFC  5494,  RFC  4361,  RFC  6842,  and  RFC  3396.  Retrieved  3  June  2015.  Available  at 
http  ://datatracker.  ietf  org/doc/rfc2 131/. 

"  Internet  Engineering  Task  Force.  “Service  Focation  Protocol,  Version  2.”  RFC  2608.  June  1999.  Updated  by 
RFC  3224.  Retrieved  3  June  2015.  Available  at  http://datatracker.ietf.org/doc/rfc2608/. 
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Table  10-10.  Ethernet  Service  Location  Protocol  Characteristics 

Characteristic 

Provision 

Type 

Value 

Naming  Authority 

Optional 

String 

RCC.  If  used,  the  service  name  shall  be 
service:RMM.RCC:IRIG  106: 

Al 

ttributes 

Product 

Optional 

String 

Identification  of  manufacturer,  vendor,  and/or 
part  number  of  the  RMM 

SerialNo 

Optional 

String 

Identification  of  the  unique  RMM 

Capacity 

Optional 

Integer 

Size  of  the  RMM  in  gigabytes,  rounded  up. 

Note:  If  present,  the  produet  string,  serial  number,  and  eapaeity  attributes  shall  be  used  solely  to 
identify  a  partieular  RMM,  and  shall  not  be  used  to  modify  the  behavior  of  the  ground  system. 

d.  Ping  Response.  The  RMM  shall  respond  to  an  internet  control  message  protocol  echo 
request  lAW  RFC  192}^ 

e.  Accessing  RMM  Storage.  In  addition  to  the  mandatory  control  interface  via  Telnet,  the 
RMM  bulk  storage  device  shall  support  at  least  one  of  the  following  two  methods  of 
accessing  data,  and  may  support  both: 

(1)  iSCSI.  To  facilitate  random  access,  the  iSCSI  protocol  lAW  IETF  RFC  3270^^  and 
the  companion  RFC  5048  may  be  implemented  according  to  Subsection  10.9.3.3. 

(2)  File  Transfer  Protocol.  To  facilitate  efficient  downloading  with  low  overhead,  the 
file  transfer  protocol  (FTP)  lAW  IETF  RFC  959^^  with  optional  extensions  lAW 
RFC  3659^^  may  be  implemented  according  to  Subsection  10.9.3.4. 

10.9.3.3  iSCSI  Data  Access  Method 

The  RMM  shall  act  as  an  iSCSI  target  and  a  host  computing  platform  shall  act  as  the 
iSCSI  initiator.  The  RMM  shall  implement  the  commands  defined  by  Subsection  10.9.11  when 
sent  using  iSCSI  CDBs. 

10.9.3.3.1  iSCSI  Session  Establishment 

The  RMM  shall  support  iSCSI  features  described  in  this  section,  sufficient  to  establish  an 
iSCSI  full-feature  phase  between  the  ground  system  and  the  RMM. 


Internet  Engineering  Task  Force.  “Internet  Control  Message  Protocol.”  RFC  792.  September  1981.  Updated  by 
RFC950,  RFC  4884,  RFC  6633,  RFC  6918.  Retrieved  3  June  2015.  Available  at 
http://datatracker.  ietf.  org/doc/rfc7 92/. 

Internet  Engineering  Task  Force.  “Multi -Protocol  Label  Switching  (MPLS)  Support  of  Differentiated  Services.” 
RFC  3270.  May  2002.  Updated  by  RFC  5462.  Retrieved  3  June  2015.  Available  at 
http  ://datatracker.  ietf  org/doc/rfc327 0/. 

Internet  Engineering  Task  Force.  “Internet  Small  Computer  System  Interface  (iSCSI)  Corrections  and 
Clarifications.”  RFC  5048.  October  2007.  Updated  by  RFC  7146,  obsoleted  by  RFC  7143.  Retrieved  3  June  2015. 
Available  at  http://datatracker.ietf  org/doc/rfc5048/. 

Internet  Engineering  Task  Force.  “File  Transfer  Protocol  (FTP).”  RFC  959.  October  1985.  Updated  by  RFC 
7151,  RFC  5797,  RFC  2773,  RFC  2228,  RFC  2640,  RFC  3659.  Retrieved  3  June  2015.  Available  at 
http  ://datatracker.  ietf  org/doc/rfc959/. 

Internet  Engineering  Task  Force.  “Extensions  to  FTP.”  RFC  3659.  March  2007.  May  be  superseded  or 
amended  by  update.  Retrieved  3  June  2015.  Available  at  http://datatracker.ietf  org/doc/rfc3659/. 
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a.  IPsec.  IPsec  shall  not  be  used. 

b.  Login  Seeuiity.  The  ground  system  shall  invoke  the  iSCSI  login  phase  with  the 
LoginOperationalNegotiation  stage.  The  Security  Negotiation  stage  shall  not  be  used. 

e.  Target  Naming.  When  an  iSCSI  target  name  is  required,  e.g.,  as  a  result  of  a  SendTargets 
exehange,  the  RMM  shall  provide  exaetly  one  IQN  per  supported  target.  The  name  shall 
take  the  form: 


iqn.yyyy-IO.org.tscc:  RMM:CHIO.vvvvvvvv-ssssss 


Where  yyyy  is  the  year  corresponding  to  the  applicable  version  of  this  standard  and 
vvvvvvvv-555555  is  a  pair  of  arbitrary  length  strings  separated  with  a  “-’’that  identify  the 
manufacturer/vendor  and  part  identifier  of  the  type  of  RMM  and  the  serial  number  or 
other  unique  identifier  of  that  particular  RMM.  These  strings  shall  not  contain  a  colon 
symbol. 


An  RMM  may  support  multiple  targets.  The  name  format 
described  above  shall  not  be  used  for  any  target  that  does  not 
adhere  to  this  standard,  e.g.,  for  non-compliant  storage  areas. 


d.  Header  and  Data  Digests.  Error  detection  digests  shall  not  be  required,  but  may  be 
supported. 

e.  Redirection.  The  RMM  shall  not  employ  redirection  via  the  TargetAddress  and 
TargetPortalGroupTag  keys. 

f.  Burst  and  Segment  Lengths.  The  RMM  and  the  ground  station  shall  support  the  default 
values  per  RFC  3720.^’ 

g.  Other  Keys.  For  features  to  be  negotiated  during  the  login  phase  not  otherwise  specified, 
the  RMM  and  the  ground  station  shall  support  the  default  values  per  RFC  3720. 

10.9.3.4  FTP  Data  Access  Method 

The  RMM  shall  implement  an  FTP  server,  and  shall  support  image  (aka  binary)  data 
representation  and  passive  mode.  Unless  changed  by  means  of  the  .TCPPORTS  command,  the 
RMM  shall  employ  TCP  port  921.  By  default,  the  RMM  shall  accept  a  login  username  of 
“IRIG:CH10”  with  the  associated  password  “RMM:FTP”.  The  RMM  may  also  support 
anonymous  FTP.  If  so  the  RMM  shall  provide  a  mechanism  to  disable  this  feature. 

The  RMM  FTP  server  shall  respond  with  an  error  code  550  and  take  no  action  in 
response  to  the  DELE,  MKD,  RMD,  RNFR,  and  RNTO  commands. 

10.9.4  RMM  High-Level  Command  Handling 

Removable  devices  shall  implement  high-level  Chapter  6  commands  in  addition  to  the 
data  transport  commands.  These  high-level  commands  and  the  associated  responses  shall  be 
transported  to  the  RMM  depending  on  the  host  platform  interface  in  use. 


Internet  Engineering  Task  Force.  “Internet  Small  Computer  Systems  Interface  (iSCSI).”  RFC  3720.  April  2004. 
Obsoleted  by  RFC  7143.  Retrieved  3  June  2015.  Available  at  http://datatracker.ietf.org/doc/rfc3720/. 
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10.9.4.1  High-Level  Commands  for  IEEE  1394b  Host  Platform  Interface 

When  using  the  IEEE  1394b  interface,  the  SEND  and  RECEIVE  processor  device  SCSI- 
2  commands  shall  be  implemented.  The  Chapter  6  commands  and  data  will  be  transported  using 
these  SCSI  commands  and  the  data  buffers. 

10.9.4.2  High-Eevel  Commands  for  Ethernet  Host  Platform  Interface 

When  using  the  Ethernet  interface,  the  RMM  shall  support  a  Telnet  server  lAW  lETE 
REC  854  using  TCP  port  923 

10.9.5  Mandated  Connectors 

Distinct  from  the  recorder/RMM  data  interface,  the  removable  media  shall  use  the 
connector  mandated  for  the  host  platform  interface  type. 

10.9.5.1  IEEE  1394b  Interface  Connector 

The  connector  type  for  the  removable  media  shall  be  an  IEEE  1394b  bilingual  socket 
connector.  Power  for  the  removable  media  shall  be  derived  from  the  bilingual  interface 
connector. 

10.9.5.2  Ethernet  Connector  -  Data 

The  connector  type  for  the  removable  media  data  connection  shall  be  an  8P8c,  commonly 
known  as  RJ45,  connector.  Power  may  also  be  supplied  using  this  connector  by  means  of  the 
POE  mechanism. 

10.9.5.3  Ethernet  Connector  -  Power 

The  connector  type  for  power  when  using  Ethernet  shall  be  a  socket  that  accepts  a  barrel 
plug  with  a  5.5-millimeter  (mm)  outside  diameter,  a  2.5-mm  inside  diameter,  and  a  shaft  length 
of  9.5  mm.  The  plug  shall  be  wired  center-positive,  and  the  connector  shall  carry  a  current  of  at 
least  5  amps. 

10.9.6  Real-Time  Clock 

Removable  media  configured  with  a  real-time  clock  can  optionally  allow  for  time  to  be 
preset  in  the  media,  allowing  for  the  transfer  to  the  recorder. 

10.9.6.1  Minimum  Operational  Requirements 

If  an  optional  real-time  clock  is  implemented,  its  time  setting  accuracy  shall  be  better 
than  1  ms.  The  short  time  accuracy  of  the  real-time  clock  device  must  be  at  least  10  parts  per 
million  (ppm)  in  the  temperature  range  0-40°C,  and  at  least  50  ppm  in  the  temperature  range 
-40°C  -  -i-85°C. 

10.9.6.2  Accessing  time  using  the  IEEE  1394b  Host  Platform  Interface 

The  SCSI  command  set  shall  be  utilized  to  access  time  on  the  cartridge. 


10-33 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  10,  July  2017 


a.  Real-Time  Clock  Time  Format.  If  an  optional  real-time  clock  is  implemented  the  time 
format  shall  be  lAW  Chapter  6  Subsection  6.2.3.10.  The  date  format  shall  be  lAW  ISO 
8601:2004.'^ 

b.  Real-Time  Clock  Logical  Unit  Number.  The  standard  SCSI  media  devices  are  using 
LUN  =  0.  The  real-time  clock  shall  be  assigned  LUN  =  1. 

10.9.6.3  Accessing  time  using  the  Ethernet  Host  Platform  Interface 

If  an  optional  real-time  clock  is  implemented  the  cartridge  time  shall  be  accessed  via  the 
.TIME  command  including  the  precision  time  protocol  extensions  if  supported. 

10.9.7  Mandatory  Commands  for  RMM  Devices 

The  required  command  set  for  RMM  devices  is  defined  by  Chapter  6,  Section  6.5. 

10.9.8  Date  and  Time  Setting  Requirements 

To  support  setting  the  time  and  date  of  the  real-time  clock,  the  RMM  should  follow  the 
procedures  defined  by  Chapter  6,  Subsection  6.5.2. 

10.9.9  Checking  Battery  Status 

Verification  of  health  of  battery  shall  be  accomplished  with  .CRITICAE  and  .HEAETH 
commands  lAW  Chapter  6,  Subsection  6.2.3. 1  and  Subsection  6. 2. 3. 3. 

10.9.10  Declassification  Supporting  Commands 

Commands  to  support  sanitization  for  declassification  or  other  purposes  are  described  in 
Chapter  6,  Subsection  6.5.3. 

10.9.11  SCSI  and  iSCSI  Devices 

The  mandatory  SCSI  command  set  is  defined  in  Chapter  6,  Subsection  6.5.4. 

10.9.12  Using  IEEE  1394b 

The  mandatory  ORB  formats  and  related  command  information  is  documented  in 
Chapter  6,  Subsection  6.5.5. 

10.9.13  Using  Ethernet 

Additional  mandatory  commands  required  when  using  Ethernet  are  documented  in 
Chapter  6,  Subsection  6.5.6. 


NOTE^ 

The  RMMs  using  IEEE  1394b,  SCSI  or  iSCSI  shall  support 

as  a  minimum  the  SCSI  command  set  to  support  data 

r 

download  lAW  Section  10.4. 

10.10  Ground-Based  Recorders 

This  section  specifies  the  basic  requirements  of  ground-based  recorders.  The  main 
functional  requirements  of  ground-based  recorders  areas  follows. 


International  Organization  for  Standardization.  Data  elements  and  interchange  formats— Information 
interchange— Representation  of  dates  and  times.  ISO  8601:2004.  Geneva:  International  Organization  for 
Standardization,  2004. 


10-34 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  10,  July  2017 


a.  Recorder  Interface 

b.  Recorder  Data  Format 

c.  Recorder  Media 

d.  Recorder  Command  and  Control  (if  the  ground-based  recorder  is  to  be  controlled 
remotely) 

Optionally,  ground-based  recorders  may  support  replay,  reproduction,  and  display  of 
Chapter  10  data  recordings.  Basic  replay  and  reproduction  interoperability  requirements  will  be 
defined  in  this  section.  Data  display  requirements  are  outside  the  scope  of  this  standard  and  will 
not  be  defined. 


10.10.1  Interface 

a.  At  a  minimum,  the  required  ground-based  recorder  interface  shall  be  Ethernet  for  remote 
command  and  control  lAW  Section  10.4  and  Section  10.7. 

b.  Optionally,  ground-based  recorders  can  implement  additional  interfaces  for  remote 
command  and  control,  remote  data  access,  and/or  data  streaming.  If  a  ground-based 
recorder  uses  iSCSI  or  contains  an  RS-232/422,  IEEE  1394,  and/or  Eibre  Channel  for 
these  interfaces,  it  shall  be  lAW  Section  10.4  and  Section  10.7. 

c.  Data  streaming 

•  The  recorder  can  optionally  have  the  capability  to  stream  Chapter  10  format  data 
(Subsection  10.10.2)  out  of  its  required  Ethernet  interface  lAW  Subsection  10.3.9.1. 

•  Stream  commit  time  as  defined  in  Subsection  10.6.1  item  c  shall  apply  to  Ethernet 
interface  data  streaming. 

10.10.2  Data  Eormat 

Ground-based  recorders  shall  format,  multiplex,  and  record  all  data  lAW  Section  10.6. 


10.10.3  Recording  Media 

Ground-based  recorders  shall  record  data  lAW  Subsection  10.10.2  to  COTS  media.  The 
term  COTS  is  defined  as  any  recording  media  (such  as  hard  disks,  solid-state  drives,  tape. 
Redundant  Array  of  Independent  Disks,  and  Just  a  Bunch  of  Disks)  that  is  ready-made  and 
available  for  sale  to  the  general  public. 


The  COTS  media  shall  have  an  electrical  interface  (such  as  Parallel  Advanced 
Technology  Attachment,  Serial  Advanced  Technology  Attachment,  IEEE  1394,  Universal  Serial 
Bus,  SCSI,  Ethernet)  to  the  ground-based  recorders  that  is  ready-made  and  available  for  sale  to 
the  general  public. 


NOTE 


If  ground-based  recorders  use  COTS  media  for  recording  of  the  Subsection 
10.10.2  data  format,  the  recorded  data  remote  data  access  at  a  minimum 
shall  be  across  the  required  ground-based  recorder  Ethernet  interface  using 
iSCSI  lAW  Subsection  10.4.3  and  Section  10.5. 
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NOTE 


If  ground-based  recorders  provide  remote  data  access  across  the  ground-based 
recorder  Ethernet  interface,  the  interface  file  structure  described  in  Section  10.5 
at  a  minimum  shall  be  presented  at  the  interface.  This  does  not  dictate  which 
COTS  media  format  or  data  organization  is  implemented,  but  does  require  that 
the  interface  file  structure  is  presented  at  the  recorder  Ethernet  interface. 


All  COTS  media  used  by  ground-based  recorders  shall  provide  the  capability  of 
recording  valid  Chapter  10  original  recording  file(s)  lAW  Section  10.11.  All  Section  10.1 1  data 
transfer  and  file  management  requirements  shall  apply  to  ground-based  recorders. 

10.10.4  Remote  Command  and  Control 

a.  Optionally,  if  a  ground-based  recorder  is  controlled  remotely,  it  shall  provide  command 
and  control  lAW  Subsection  10.7.8  across  the  Ethernet  interface  port  as  defined  in 
Subsection  10.10.1. 

b.  Ground-based  recorders  at  a  minimum  are  required  to  use  iSCSI  or  Telnet  as  the 
command  and  control  Ethernet  transport  mechanism  as  defined  in  Section  10.4  and 
Section  10.7. 

c.  Ground-based  recorders  providing  remote  command  and  control  capability  shall  provide 
the  functionality  for  all  commands  defined  in  Subsection  10.7.8. 

d.  Optionally,  if  a  ground-based  recorder  contains  an  RS-232/422/485,  IEEE  1394b,  and/or 
Eibre  Channel  interface  as  defined  in  Subsection  10.10.1  the  recorder  will  provide 
command  and  control  lAW  Section  10.7  and  Chapter  6. 

10.10.5  Data  Replay  and  Reproduction 

10.10.5.1  Channel  Mapping 

a.  Optionally,  if  a  ground-based  recorder  provides  data  playback  capability,  it  shall  provide 
for  the  logical  assignment  of  recorded  channels  to  physical  channels  on  the  ground-based 
recorders. 

b.  Playback  will  not  require  movement  of  cards  between  slots  to  make  assignments  for 
playback. 

10.10.5.2  Recording/Reproduction  Data  Rates 

Optionally,  if  a  ground-based  recorder  provides  a  data  playback  capability,  it  shall 
provide  information  using  the  Chapter  6  .CRITICAE  and  .HEAETH  commands  (Subsection 
6.2.3. 1  and  Subsection  6. 2. 3. 3)  if  the  bandwidth  of  data  to  be  played  back  exceeds  the  aggregate 
bandwidth  of  the  ground-based  recorder. 

10.10.5.3  Network  Recording  Playback 

a.  Optionally,  if  a  ground-based  recorder  provides  a  data  playback  capability,  it  shall 
provide  replay  from  COTS  media  (Subsection  10.10.3)  to  the  Ethernet  interface.  The 
Ethernet  format  of  the  network  recording  playback  will  be  lAW  Subsection  10.3.9. 

b.  If  the  network  recording  playback  capability  is  commanded  remotely,  ground-based 
recorders  shall  support  the  functionality  specified  in  Chapter  6. 
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10.11  Data  Interoperability 

10.11.1  Original  Recording  Files 

All  files  contained  within  a  recorder,  RMM,  COTS  media,  or  that  are  a  byte-for-byte 
single  file  downloaded  to  a  host  computing  platform  in  unaltered  form  shall  be  considered 
original  recording  files  and  be  in  full  compliance  with  the  data  organization  in  Subsection  10.5.1 
and  data  format  in  Section  10.6. 

In  order  to  provide  a  standardized  method  of  annotation  for  original  recording  files,  the 
following  procedures  shall  be  used  to  ensure  Chapter  10  compliance: 

•  The  Computer-Generated  Data,  Format  1  setup  record  shall  always  contain  the 
required  attributes  lAW  Section  10.11. 

•  The  original  recording  file  setup  record  R-x\RI3  “Original  Tape/Storage”  attribute 
value  shall  be  R-x\RI3:Y; 

10.11.2  Modified  Recording  Files 

Modified  recording  files  are  created  from  original  recording  files  directly  from  a 
recorder,  RMM,  COTS  media,  or  from  original  recording  files  that  have  been  downloaded  to  a 
host  computing  platform.  There  are  several  instances  of  modified  recording  files-filtered  or 
sanitized  data,  a  subset  of  channels,  a  superset  of  channels,  a  subset  of  time,  a  subset  of  both 
channels  and  time,  or  a  superset  of  channels  and  subset  of  time. 

10. 1 1 .2. 1  Modified  Recording  File  Annotation 

In  order  to  provide  a  standardized  method  of  annotation  for  modified  recording  files,  the 
following  procedures  shall  be  used  to  ensure  Chapter  10  compliance. 

a.  The  Computer-Generated  Data,  Format  1  setup  record  shall  always  contain  the  required 
attributes  lAW  Section  10.1 1. 

b.  Any  time  a  modification  is  made  to  an  original  recording  the  R-x\RI3  Original 
Tape/Storage  attribute  value  shall  be  changed: 

From:  R-x\RI3:Y; 

To:  R-x\RI3:N; 

In  addition,  the  R-x\RI6  Date  of  Modification  attribute  will  be  added  if  not  already 
present,  in  which  case  if  R-x\RI3  contains  a  “Y”  R-x\RI6  shall  be  empty.  The  R-x\RI8 
attribute  value  shall  contain  the  last  date  and  time  the  modified  recording  file  was 
created. 

c.  If  the  modified  recording  file  is  not  a  time  subset  but  either  a  channel  subset  or  both  a 
time  and  channel  subset,  then  the  step  b  attributes  shall  be  changed  as  defined.  The 
original  channels  that  are  not  included  in  the  recording  subset  file  shall  have  the  R- 
x\CHE-n  Channel  Enable  attribute  changed: 

Erom:  R-x\CHE-n:T; 

To:  R-x\CHE-n:E; 

A  comment  attribute  R-x\COM  will  be  inserted  directly  after  the  changed  R-x\CHE-n 
attribute  and  shall  contain  the  following: 
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“original  recording  change -removed  channel-n”  (where  n  represents  the  channel  ID 
of  the  channel  that  was  removed). 

d.  If  the  modified  recording  file  is  not  a  time  subset  but  either  a  channel  superset  or  both  a 
time  subset  and  channel  superset,  then  the  step  b  attributes  shall  be  changed  as  defined. 

In  addition,  the  channels  added  in  the  modified  recording  file  shall  contain  the  required 
attribute  lAW  Section  10.1 1. 

A  comment  attribute  R-x\COM  will  be  inserted  directly  after  the  added  channel  R- 
x\CHE-n  attribute  and  shall  contain  the  following: 

“original  recording  change-additional  channel-n”  (where  n  represents  the  channel 
ID  of  the  channel  that  was  added). 

If  the  modified  recording  file  contains  filtered  (removed  packets  or  data)  or  sanitized  data 
(overwrite  of  data),  then  the  step  b  attributes  shall  be  changed  as  defined.  Also  the 
channels  that  contain  filtered  or  sanitized  data  in  the  modified  recording  file  shall  also 
contain  a  comment  attribute  R-x\COM  inserted  directly  after  the  channel  R-x\CHE-n 
attribute  and  shall  contain  the  following: 

“original  recording  change-filtered  channel-n”  (where  n  represents  the  channel  ID 
of  the  channel  that  was  filtered). 

10.11.2.2  Modified  Recording  Eile  Restructuring 

When  a  modified  recording  file  is  created  there  will  be  alterations  to  original  packets  or 
possibly  structure.  Therefore: 

a.  All  files  shall  reflect  any  sequence  number,  packet  length,  or  checksum  changes  in  the 
appropriate  packet  header  fields. 

b.  If  enabled  in  the  original  recording.  Computer- Generated  Data,  Eormat  3  recording  index 
packets  shall  be  recalculated  to  ensure  correct  information  is  contained  within  the  entries 
as  they  relate  to  the  newly  created  modified  recording  file. 

10.11.3  Original  Recording  and  Modified  Recording  Eile  Extension 

Upon  data  download  to  a  host  computing  platform,  all  original  and/or  modified  recording 
files  shall  use  the  file  extension  *.chl0  (or  *.cl0  extension  for  use  on  systems  with  a  3-character 
extension  limit).  The  use  of  this  standard  extension  will  indicate  that  any  original  and/or 
modified  recording  file  on  a  ground  computing  or  storage  platform  shall  be  lAW  this  section. 

10.11.4  Eile  Naming 

Upon  data  download  from  the  recorder  or  RMM  to  a  host  computing  platform,  all  or 
modified  recording  files  shall  use  the  following  structure  and  naming  conventions  unless  the  host 
computing  platform  operating  system  imposes  naming  length  limits.  In  this  case  the  directory 
and  file  names  are  to  be  truncated  after  the  last  component  that  completely  fits  within  the  name 
length  limit. 

10.11.4.1  On-Board  Recorder 

a.  Data  Recording  Directory  Name.  Each  directory  block  from  an  RMM  to  be  downloaded 
to  a  ground  computing  or  storage  platform  shall  use  VolName  as  defined  in  Table  10-6  as 
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the  directory  name  where  the  data  files  will  be  placed.  The  directory  name  shall  use 
lower-case  letters. 

If  the  VolName  is  empty  (0x00),  a  default  name  or  user-defined  name  shall  be  used.  If 
used  the  default  name  shall  be  chlOdirnnn,  where  nnn  is  the  sequential  directory  block 
count. 

b.  Data  File  Name.  Each  data  file  contained  within  a  directory  block  on  the  RMM  to  be 
downloaded  will  be  placed  in  the  directory  identified  in  item  a  above  and  shall  use  the 
following  naming  convention.  The  data  file  name  shall  use  lower-case  letters. 

“filennnn”;  where  nnnn  is  the  sequential  RMM  file  count  from  each  directory  block 
file  entry  (must  be  8  alpha-numeric  characters). 

Example:  “file0001,”“file0002,”  ...:”file9999.” 

If  available,  Eile  Create  Date,  Eile  Create  Time,  and  Eile  Close  Time  from  Table 
10-7,  DDMMYYYY_HHMMSSss_HHMMSSss  (8  numeric  characters  for  Eile 
Create  Date,  8  numeric  characters  for  Eile  Create  Time  separated  by  an  underscore 
ASCII  character  code  0x5E,  and  8  numeric  characters  for  Eile  Close  Time).  No 
spaces  or  other  non-numeric  characters  allowed. 

Example:  02092004_2 1 30273 1_2 145 1 505 . 

If  the  Eile  Create  Date,  Eile  Create  Time,  and  Eile  Close  Time  values  are  not  available 
and  are  filled  with  0x2D,  then  the  system  time  from  the  host  download  platform  will  be 
used  for  Eile  Create  Date  and  Eile  Create  Time  (DDMMYYYY_HHMMSS).  Eile  Close 
Time  will  not  be  used.  Eile  Close  Time  shall  be  replaced  with  sys_time. 

A  structure  example  follows: 

...\VolName\EileName_EileCreateDate_EileCreateTime_EileCloseTime 

When  VolName  not  empty  example: 

. .  .\<VolName>\file0001_02092004_21302731_21451505.chl0 

When  VolName  empty  default  example: 

. . .  \ch  1  OdirOO  RfileOOO  1  _02092004_2 1 30273 1_2 1 45 1 505  .eh  1 0 

When  VolName  empty  user  defined  example: 

. .  .\<User  Defined>\file0001_02092004_21302731_21451505.chl0 

When  date/time  not  available  (0x2D  fill)  example: 

. .  .\file0001_02092004_213027_sys_time.chl0 

The  use  of  this  standard  recording  and  file  naming  convention  will  indicate  that  any  file 
on  a  ground  computing  or  storage  platform  is  lAW  this  standard. 

10. 1 1 .4.2  Ground-Based  Recorder 

a.  Recording  Directory  Name.  Each  directory  where  the  data  files  will  be  placed  shall  use 
the  naming  convention  \chlOdir_DDMMYYYY_nnn;  where  n  is  the  sequential  number 
of  Chapter  10  recording  directories  created  on  the  DDMMYYYY  date.  The  directory 
name  shall  use  lower-case  letters. 
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b.  Recording  File  Name.  Each  data  file  contained  within  a  directory  shall  use  the  following 
naming  convention.  The  data  file  name  shall  use  lower-case  alpha  characters. 

“filennnn”;  where  nnnn  is  the  sequential  file  count  from  each  recording  (must  be  8 
alpha-numeric  characters) 

Example:  fileOOOl,  file0002,  ...:file9999 

Eile  Create  Date,  Eile  Create  Time,  and  Eile  Close  Time  shall  use  the  following  naming 
convention. 

DDMMYYYY_HHMMSSss_HHMMSSss  (8  numeric  characters  for  Eile  Create 
Date,  8  numeric  characters  for  Eile  Create  Time  separated  by  an  underscore  ASCII 
character  code  0x5E,  and  8  numeric  characters  for  Eile  Close  Time).  No  spaces  or 
other  non-numeric  characters  allowed. 

Example:  02092004_2 1 30273 1_2 145 1 505 . 

A  structure  example  follows. 

...\chl0dir_02092005_001\file0001_02092005_21302731_21451505.chl0 

The  use  of  this  standard  recording  and  file  naming  convention  will  indicate  that  any  file 
on  a  ground  computing  or  storage  platform  is  lAW  this  standard. 


10.11.5  Data  Transfer  Eile 

In  order  to  ensure  the  highest  degree  of  interoperability  for  transfer  of  Chapter  10 
recorder  or  RMM  contents  or  original  or  modified  recording  files  between  organizations,  the  data 
transfer  file  structure  shall  be  used.  Essentially,  a  data  transfer  file  contains  all  the  same 
information  and  data  that  a  recorder  or  RMM  would  present  at  the  interface  albeit  within  a  single 
binary  structure  on  either  tape  or  random  access  devices.  The  data  transfer  file  could  also 
contain  original  or  modified  recording  files  from  multiple  recordings  or  dates. 


NOTE  ^ 


Original  or  modified  recording  files  downloaded  to  a  host 
computing  platform  and  transferred  as  a  single  file  shall  follow 
Subsection  10.1 1.1  and  Subsection  10.11.2. 


10. 1 1 .5. 1  Data  Transfer  Eile  Structure  Definition 

The  following  describes  data  transfer  file  structure  and  media  environments. 

a.  Tape  Devices.  A  data  transfer  file  on  tape  devices  is  treated  essentially  the  same  as  a 
recorder  or  RMM  in  that  the  directory  structure  and  data  contents  are  as  defined  and 
organized  in  this  standard.  The  data  transfer  file  is  a  single  binary  file  containing  a 
directory  structure  lAW  Section  10.5  and  a  single  or  multiple  Chapter  10  original 
recording  files  or  modified  recording  files.  Only  one  data  transfer  file  will  be  contained 
on  a  tape  device  media.  The  tape  block  size  shall  be  32  kb. 

•  Eogical  address  1  will  contain  a  directory  and  file  structure  lAW  Subsection  10.5.2. 

•  The  corresponding  Chapter  10  original  recording  files  or  modified  recording  files  will 
follow  the  directory  structure  in  contiguous  bytes  until  the  end  of  the  data  transfer 
file.  The  beginning  of  each  Chapter  10  original  or  modified  recording  file  in  the  data 
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transfer  file  will  begin  at  the  byte  offset  contained  in  each  file  entry  table  file  Start 
Address  value. 

b.  Random  Access  Devices.  A  data  transfer  file  on  a  random  access  device  is  treated 
essentially  the  same  as  a  recorder  RMM  in  that  the  directory  structure  and  data  contents 
are  as  defined  and  organized  in  this  standard.  The  data  transfer  file  is  a  single  binary  file 
containing  a  directory  structure  lAW  Subsection  10.5.2  and  a  single  or  multiple  Chapter 
10  original  or  modified  recording  files.  Multiple  data  transfer  files  can  be  contained  on  a 
random  access  device. 

•  The  Subsection  10.5.2  directory  structure  within  the  data  transfer  file  begins  at  byte  0 
and  runs  contiguously  until  the  last  file  entry  paragraph.  The  next  byte  after  the  last 
file  entry  block  shall  be  the  first  byte  in  the  first  data  file. 

•  The  corresponding  Chapter  10  original  or  modified  recording  files  will  follow  the 
directory  structure  in  contiguous  bytes  until  the  end  of  the  data  transfer  file.  The 
beginning  of  each  Chapter  10  original  or  modified  recording  file  in  the  data  transfer 
file  will  begin  at  the  byte  offset  contained  in  each  file  entry  table  file  Start  Address 
value. 

10.1 1.5.2  Data  Transfer  File  Extension 

Upon  creation,  all  Chapter  10-compliant  data  transfer  files  not  on  tape  devices  shall  use 
the  file  extension  *.tfl0  (or  *.tl0  extension  for  use  on  systems  with  a  3  character  extension 
limit).  The  use  of  this  standard  extension  will  indicate  that  any  data  transfer  file  on  a  host 
computing  or  storage  platform  shall  be  lAW  Subsection  10.11.5 

10.11.6  Recording  Directory  File 

A  recording  directory  file  is  a  binary  file  that  is  a  byte-for-byte  copy  of  the  RMM  or 
recorder  directory  structure  presented  at  the  interface.  This  file  should  represent  the  contents  of 
an  RMM  or  recorder  directory  at  the  time  of  Chapter  10  data  download.  The  bytes  in  this  file 
contain  the  byte-for-byte  contents  of  the  RMM’s  directory  blocks  in  the  order  the  directory 
blocks  are  linked,  using  each  block’s  forward  link  field. 

10. 1 1 .6. 1  Recording  Directory  File  Extension 

Upon  creation,  all  Chapter  10-compliant  recording  directory  files  shall  use  the  file 
extension  *.dfl0  (or  *.dl0  extension  for  use  on  systems  with  a  three-character  extension  limit). 
The  use  of  this  standard  extension  will  indicate  that  any  recording  directory  file  on  a  host 
computing  or  storage  platform  shall  be  lAW  Subsection  10.11.6. 
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APPENDIX  10-A 
Definitions 

The  following  are  definitions  that  are  used  in  this  standard  and  are  provided  as  a  means  of 

removing  ambiguities  within  the  standard. 

Absolute  Time:  A  hypothetical  time  that  either  runs  at  the  same  rate  for  all  the  observers  in  the 
universe  or  the  rate  of  time  each  observer  can  be  scaled  to  by  multiplying  the  observer’s 
rate  by  a  constant. 

Block:  The  smallest  unit  of  addressable  memory  that  can  be  written  to,  read  from,  and/or  erased. 

Bad  Block:  A  block  determined  to  be  unreliable  for  storing  user  data. 

Bad  Block  Table:  A  table  of  bad  block  entries  for  a  memory  board.  The  data  stored  in  the  entry 
identifies  the  chip  and  block  number  of  the  bad  block.  The  table  entry  also  contains  a 
flag  field.  The  flag  field  is  used  to  determine  the  circumstance  in  which  the  bad  block 
was  detected.  It  also  provides  a  flag  indicating  whether  the  corresponding  bad  block  has 
previously  been  secure  erased. 

Byte:  A  contiguous  set  of  8  bits  that  are  acted  on  as  a  unit. 

Channel-Specific  Data  Word:  A  required  word  for  each  data  type  channel  that  has  data-specific 
information. 

Data  Streaming:  Streaming  of  current  value  data  whether  it  is  being  recorded  or  not,  and 

playback  streaming  of  recorded  data  from  a  file.  Data  streaming  sends  the  data  to  one  or 
more  destinations  simultaneously  (e.g.,  recording  media,  recorder  data  interfaces). 

Extended  Relative  Time  Counter:  A  1-GHz  extension  to  the  existing  10-MHz  RTC. 

Long  Word:  A  contiguous  set  of  32  bits  that  are  acted  on  as  a  unit. 

Mandatory:  Defines  a  mandatory  requirement  of  this  standard  for  full  compliance.  Mandatory 
requirements  as  defined  in  this  standard  are  based  on  the  use  of  “shall”. 

Memory  Clear:  Rendering  stored  information  unrecoverable  unless  special  utility  software  or 
techniques  are  used. 

Memory  Sanitization:  The  removal  of  information  from  information  system  media  such  that 
data  recovery  using  known  techniques  or  analysis  is  prevented.  Sanitizing  includes  the 
removal  of  data  from  the  media  and  verification  of  the  action.  Properly  sanitized  media 
may  be  subsequently  declassified  upon  observing  the  organization’s  respective 
verification  and  review  procedures. 

Multiplexer:  The  entity  that  includes  all  the  inputs,  control  interfaces,  and  functionality  required 
to  properly  record  data. 

Non-volatile:  Memory  media  that  retains  data  when  power  is  removed. 

Packet:  Encapsulates  a  block  of  observational  and  ancillary  application  data  to  be  recorded. 

Packet  Generation:  The  placing  of  observational  and  ancillary  data  into  a  packet. 
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Page:  Storage  unit  within  the  flash  memory.  A  page  is  the  smallest  storage  unit  that  can  be 
written. 

Playback:  See  Replay 

Reconstruction:  The  output  of  a  recorder  where  the  timing  and  data  content  of  the  output  signal 
are  identical  to  the  timing  and  data  content  of  the  originally  recorded  signal.  This  is 
generally  the  case  where  the  input  signal  is  captured  using  digital  sampling  techniques. 
Also  see  Reproduction. 

Recorder:  Is  used  where  a  function  or  requirement  shall  apply  to  both  an  on-board  recorder  and 
a  ground-based  recorder. 

Recording:  Is  defined  as  the  time  interval  from  first  packet  generated  (which  by  mandatory 
requirements  is  a  Computer-Generated  Data  Packet,  Format  1)  and  committed  to  the 
recorder  media  to  the  last  packet  generated  and  committed  to  the  recorder  media.  Packet 
generation  time  and  stream  commit  time,  as  defined  within  the  standard,  apply. 

Removable  Memory  Module:  The  element  of  the  on-board  recorder  that  contains  the  stored 
data. 

Replay:  The  virtual  reconstruction  of  a  recorded  signal.  This  virtually  reconstructed  signal 
exists  for  the  purposes  of  display,  presentation,  extraction,  or  retransmission. 

Reproduction:  The  output  of  a  recorder  where  the  electrical  characteristics  of  the  output  signal 
are  identical  to  the  characteristics  of  the  originally  recorded  signal.  This  is  generally  only 
achievable  when  the  input  signal  is  captured  using  analog  recording  techniques.  Also  see 
Reconstruction. 

Setup  Record:  TMATS  lAW  Chapter  9  annotated  in  the  Computer-Generated  Data,  Format  0 
packet. 

Stream:  All  packets  from  all  enabled  channels  (including  computer-generated  data)  that  are 
generated  until  the  end  of  a  recording. 

Stream  Commit  Time:  The  time  span  in  which  all  generated  packets  must  be  committed  to  a 
stream. 

Word:  A  contiguous  set  of  16  bits  acted  on  as  a  unit. 
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APPENDIX  10-B 
Sanitization 

Associated  documents  such  as  National  Security  Agency  Manual  9-12,*^  DoD  Directive 
5200.28,^°  and  DCID  6/3^^  historically  covered  sanitization  guidelines/requirements.  These 
documents  focused  on  sanitization  of  standard  disk  and  other  conventional  memory  technologies. 
Sanitization  is  the  determination  by  an  authorized  official  that  classified  information  no  longer 
requires,  in  the  interest  of  national  security,  any  degree  of  protection  against  unauthorized 
disclosure.  This  standard  provides  for  the  minimum  set  of  commands  that  may  be  utilized  to 
allow  for  user  sanitization  of  solid-state  media  residing  in  an  RMM.  The  solid-state  media  may 
consist  of  COTS  solid-state  disks  or  a  memory  configuration  unique  to  the  manufacturer.  There 
are  several  approaches  for  sanitization.  The  responsibility  for  ensuring  that  a  proper  sanitization 
process  has  been  effectively  implemented  will  reside  ultimately  with  the  user/customer/program 
manager. 

B.l.  Approach 

The  following  approaches  for  sanitization  are  currently  recommended.  It  is  believed  that 
the  user  is  the  most  qualified  to  determine  the  sanitization  procedures  for  any  program  situation. 

It  is  the  user’s  responsibility  to  correctly  apply  the  guidelines  to  the  program  in  each  location  to 
optimize  the  cost/effect  while  providing  appropriate  protection  for  the  data.  The  guidelines  are 
planned  to  be  available  on  the  Internet  at  Defense  Link. 

B.2.  Algorithm 

The  algorithm  to  erase  secure  data  is  described  below.  During  the  secure  erase 
procedure,  all  blocks  of  memory  shall  be  processed.  No  block  in  memory  shall  be  excluded  from 
secure  erase  processing  for  any  reason. 

a.  First  Erase.  Every  memory  block  on  the  board  is  erased.  Any  erase  failures  reported  by 
memory  chips  will  result  in  the  corresponding  chip/block  being  declared  a  bad  block.  In 
the  event  this  bad  block  is  not  already  in  the  corresponding  board’s  bad  block  table,  a 
new  bad  block  entry  will  be  appended  onto  the  board’s  bad  block  table.  Note  that  this 
new  entry  will  not  have  the  secure  erase  flag  set. 

b.  First  Write  (0x55).  Every  memory  chip  location  is  recorded  with  the  pattern  0x55.  As 
each  location  is  written,  the  data  is  read  back  to  guarantee  that  all  bits  were  written  to  the 
expected  pattern.  Any  write  failures  reported  by  the  chips  or  any  data  errors  will  result  in 
the  corresponding  chip/block  being  declared  a  bad  block.  In  the  event  this  bad  block  is 
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not  already  in  the  corresponding  board’s  bad  block  table,  a  new  bad  block  entry  will  be 
appended  onto  the  board’s  bad  block  table.  Note  that  this  new  entry  will  not  have  the 
secure  erase  flag  set. 

c.  Second  Erase.  Every  memory  chip  shall  be  erased.  Any  erase  failures  reported  by  the 
memory  chips  will  result  in  the  corresponding  chip/block  being  declared  a  bad  block.  In 
the  event  this  bad  block  is  not  already  in  the  corresponding  board’s  bad  block  table,  a 
new  bad  block  entry  will  be  appended  onto  the  board’s  bad  block  table.  Note  that  this 
new  entry  will  not  have  the  secure  erase  flag  set. 

d.  Second  Write  (OxAA).  Every  memory  chip  location  is  recorded  with  the  pattern  OxAA. 
As  each  location  is  written,  the  data  is  read  back  to  guarantee  that  all  bits  were  written  to 
the  expected  pattern.  Any  write  failures  reported  by  the  memory  chips  or  any  data  errors 
will  result  in  the  corresponding  chip/block  being  declared  a  bad  block.  In  the  event  this 
bad  block  is  not  already  in  the  corresponding  board’s  bad  block  table,  a  new  bad  block 
entry  will  be  appended  onto  the  board’s  bad  block  table.  Note  that  this  new  entry  will  not 
have  the  secure  erase  flag  set. 

e.  Third  Erase.  Every  memory  location  is  erased.  Any  erase  failures  reported  by  the 
memory  chips  will  result  in  the  corresponding  chip/block  being  declared  a  bad  block.  In 
the  event  this  bad  block  is  not  already  in  the  corresponding  board’s  bad  block  table,  a 
new  bad  block  entry  will  be  appended  onto  the  board’s  bad  block  table.  Note  that  this 
new  entry  will  not  have  the  secure  erase  flag  set. 

f.  Usable  Secure  Erased  Blocks.  All  blocks  that  do  not  have  an  entry  in  the  bad  block  table 
are  now  considered  to  be  secure  erased. 

g.  Unusable  Secure  Erased  Blocks.  If  a  bad  block  entry  contains  the  flag  indicating  it  has 
already  been  secure  erased,  this  block  has  already  been  secure  erased  and  requires  no 
further  processing,  since  it  is  known  that  this  block  was  skipped  during  the  previous 
recording. 

h.  Unsecure  Bad  Block  Processing.  A  board’s  bad  block  table  may  contain  bad  block 
entries  that  have  not  previously  been  secure  erased.  If  any  such  entries  exist,  the 
following  steps  are  performed  on  each  block. 

•  Write  Zeros  Eoop.  Eor  each  page  in  the  block,  a  pattern  of  all  zeros  is  written  to  the 
page,  and  the  page  is  checked  to  determine  if  any  unexpected  ones  (UOs)  are  found. 

If  any  UOs  are  found,  the  page  is  re-written  to  all  zeros.  This  process  is  repeated  up 
to  16  times.  After  all  allowed  re-writes,  the  board,  chip,  and  block  numbers  of  the 
block  containing  any  remaining  UOs  are  written  to  a  failed  erase  table. 

•  Write  Ones  Eoop.  Eor  each  page  in  the  block,  the  page  is  erased  (to  all  ones)  and 
checked  to  determine  if  any  unexpected  zeros  (UZs)  are  found.  If  any  UZs  are  found, 
another  erase  command  is  issued  to  the  block.  This  process  is  repeated  up  to  16 
times.  After  all  allowed  erase  operations,  the  board,  chip,  and  block  numbers  of  the 
block  containing  any  remaining  UZs  are  written  to  the  failed  erase  table. 

i.  Tailed  Erase  Table  Processing.  Any  remaining  entries  in  the  failed  erase  table  correspond 
to  blocks  that  cannot  be  erased.  These  blocks  may  still  contain  user  data  and  therefore 
are  declared  to  have  failed  the  secure  erase. 
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A  count  of  the  number  of  bad  blocks  in  the  failed  erase  table  that  have  not  been  secure 
erased  is  returned  as  part  of  the  secure  erase  results.  A  non-zero  count  indicates  a  secure 
erase  failure  of  at  least  one  block.  A  command  will  allow  the  user  to  retrieve  the  failed 
erase  table.  A  command  will  also  allow  a  user  to  retrieve  the  data  from  such  blocks  and 
manually  determine  if  these  blocks  can  be  designated  as  “Secure  Erased.”  In  most  cases, 
a  single  stuck  bit  will  not  compromise  any  user  data  and  the  offending  block  can  be 
manually  declared  to  be  secure  erased.  If  the  results  of  manual  inspection  are 
indeterminate,  the  chip  containing  the  failed  block  must  be  removed  and  destroyed,  and 
the  secure  erase  procedure  must  be  repeated. 

j.  Secure  Erase  Completion.  When  all  blocks  are  secure  erased  (no  entries  in  the  failed 
erase  table),  the  content  of  the  file  is  the  ASCII  string  “Secure  Erase”  repeated  over  and 
over. 
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CHAPTER  11 

Packet  Format  Standard 


11.1  General 

A  large  number  of  unique  and  proprietary  data  structures  has  been  developed  for  specific 
data  recording  applications  that  required  unique  decoding  software  programs.  The  activities  of 
writing  unique  decoding  software,  checking  the  software  for  accuracy,  and  decoding  the  data 
formats  are  extremely  time-consuming  and  costly. 

Specifically,  this  packet  format  standard  shall  be  usable  with  multiplexing  of  both 
synchronous  and  asynchronous  digital  inputs  such  as  pulse  code  modulation  (PCM);  Military 
Standard  (MIL-STD)  1553  data  bus,  time,  analog,  video;  Aeronautical  Radio,  Inc.  (ARINC)  429; 
discrete;  and  Universal  Asynchronous  Receiver  and  Transmitter  (UART)  containing 
Recommended  Standard  (RS)-232/422/485  communication  data.  This  packet  standard  will 
allow  use  of  a  common  set  of  data  interpretation  libraries  to  reduce  the  cost  of  producing  data 
analysis  systems. 


NOTE^ 

Within  this  standard,  where  text,  figures,  or  tables  are 

used  to  provide  descriptions,  meaning,  and/or 

r 

explanations,  the  text  shall  take  precedence  over  figures 

and  tables. 

The  data  format  structures  (packet  header,  secondary  packet  header,  channel-specific  data 
word  [CSDW],  intra-packet  data  header  [IPDH],  and  packet  trailer)  described  in  Section  11.2  are 
defined  to  have  the  following  bit  and  byte  orientation.  The  least  significant  byte  shall  be 
transmitted  first;  the  least  significant  bit  (Isb)  of  each  byte  shall  be  transmitted  first,  with  most 
significant  bit  (msb)  transmitted  last;  and  data  is  read  from  the  lowest  logical  address  first.  This 
ordering  is  commonly  referred  to  as  “Little  Endian.”  The  packet  data  shall  remain  in  its  native 
byte  order  format. 

11.2  Data  Format  Definitions 

11.2.1  Common  Packet  Elements 

Data  shall  have  three  required  parts:  a  packet  header,  a  packet  body,  and  a  packet  trailer, 
and  an  optional  part  if  enabled,  a  packet  secondary  header.  A  packet  will  always  conform  to  the 
structure  outlined  in  Eigure  11-1. 

a.  A  packet  has  the  basic  structure  shown  in  Table  11-1.  Note  that  the  width  of  the  structure 
is  not  related  to  any  number  of  bytes  or  bits.  This  table  is  merely  to  represent  relative 
packet  elements  and  their  placement  within  the  packet.  See  Table  11-2  for  a  diagram  of 
the  generic  packet  format.  This  table  does  not  depict  the  bit  lengths  of  each  field.  Word 
sizes  of  8  bits,  16  bits,  and  32  bits  are  used  depending  on  the  data  type. 

To  further  clarify  the  packet  layout.  Table  11-2  shows  the  generic  packet  in  a  32-bit, 
little-endian  format,  and  assumes  16-bit  data  words  and  data  checksum. 
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Packet 

Header 


Optional 

Packet 

Secondary 

Header 


Packet  Body 


Packet  Trailer 


A 


V. 


Packet  Sync  Pattern 


Channel  ID 


Packet  Length 


\ 


Data  Length 


Data  Type  Version 
Sequence  Number 


Bit  7:  Indicates 
the  existence  of 
the  optional 
packet 
secondary 
header. 


Bit  6:  Indicates 
the  intra-packet 
time  stamp  time 
source. 


:  Bits  3-2:  Indicate 
,  the  packet 
secondary 
^  header  time 
format. 


Bits  1-0:  Indicate 
the  data 
checksum 
existence. 


Intra-Packet  Time  Stamp 
(Least  Significant  Long  Word) 

Intra-Packet  Time  Stamp 
(Most  Significant  Long  Word) 

Intra-Packet  Data  Header 

Filler... 


Data  Checksum 
(8  Bit,  16  Bit,  32  Bit,  or  None) 


If  00,  No  Data  Checksum  Present. 

If  01,  8-Bit  Checksum  -  If  10,  16-Bit  Checksum  -  If  11,  32-Bit  Checksum 


□J 


Figure  11-1.  Overall  Packet  Structure 


Table  11-1.  General  Packet  Structure 

PACKET  SYNC  PATTERN 

Packet  Header 

CHANNEL  ID 

PACKET  LENGTH 

DATA  LENGTH 

DATA  TYPE  VERSION 

SEQUENCE  NUMBER 

PACKET  ELAGS 

DATA  TYPE 

RELATIVE  TIME  COUNTER 

HEADER  CHECKSUM 

TIME 

Packet  Secondary 
Header  (Optional) 

RESERVED 
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SECONDARY  HEADER  CHECKSUM 

CHANNEE-SPECIEIC  DATA 

Packet  Body 

INTRA-PACKET  TIME  STAMP  1 

INTRA-PACKET  DATA  HEADER  1 

DATA  1 

INTRA-PACKET  TIME  STAMP  N 

INTRA-PACKET  DATA  HEADER  N 

DATAn 

DATA  CHECKSUM 

Packet  Trailer 

Table  11-2.  32-Bit  Packet  Format  Layout 

msb  Isb 

31  16  15  0 

CHANNEE  ID 

PACKET  SYNC  PATTERN 

Packet  Header 

PACKET  EENGTH 

DATA  EENGTH 

DATA  TYPE  PACKET  EEAGS 

SEQUENCE  DATA  TYPE 
NUMBER  VERSION 

REEATIVE  TIME  COUNTER 

HEADER  CHECKSUM 

REEATIVE  TIME  COUNTER 

TIME  (EEAST  SIGNIEICANT  EONG  WORD  [ESEW]) 

(Optional) 

Packet 

Secondary 

Header 

TIME  (MOST  SIGNIEICANT  EONG  WORD  [MSEW]) 

SECONDARY  HEADER 

CHECKSUM 

RESERVED 

CHANNEE-SPECIEIC  DATA 

Packet 

Body 

INTRA-PACKET  TIME  STAMP  1 

INTRA-PACKET  TIME  STAMP  1 

INTRA-PACKET  DATA  HEAD] 

ER  1 

DATA  1  WORD  2 

DATA  1  WORD  1 

DATA  1  WORD  N 

INTRA-PACKET  TIME  STAMP  2 

INTRA-PACKET  TIME  STAMP  2 

INTRA-PACKET  DATA  HEAD] 

ER2 

DATA  2  WORD  2 

DATA  2  WORD  1 

DATA  2  WORD  N 

INTRA-PACKET  TIME  STAMP  N 

INTRA-PACKET  TIME  STAMP  N 

INTRA-PACKET  DATA  HEAD] 

ERN 

DATA  N  WORD  2 

DATA  N  WORD  1 

DATA  N  WORD  N 

[EIEEER] 

Packet  Trailer 
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DATA  CHECKSUM 

Depending  on  the  data  type,  the  size  of  the  data  checksum  can  contain  32  bits,  16  bits,  8 
bits,  or  the  checksum  can  be  entirely  left  out.  For  a  32-bit  data  checksum,  the  packet 
trailer  would  be  as  shown  in  Figure  11-2. 


msb  Isb 

7  0 

[  Filler  ] 

Packet  Trailer 

Data  Checksum  (Isb) 

Data  Checksum 

Data  Checksum 

Data  Checksum  (msb) 

Figure  11-2.  Packet  Trailer  for  32-Bit  Data  Checksum 


b.  For  an  8-bit  data  checksum,  the  packet  trailer  would  be  as  shown  in  Figure  11-3. 


msb 

Isb 

7 

0 

[  Filler  ] 

Packet  Trailer 

Data  Checksum 

Figure  11-3. 

Packet  Trailer 

’or  8 -Bit  Data  Checksum 

c.  The  size  of  a  single  packet  may  be  a  maximum  of  524,288  (2^^)  bytes  as  shown  in  Table 
11-3.  This  includes  the  packet  header,  packet  body,  packet  trailer,  and  optional  packet 
secondary  header  if  enabled.  The  only  exception  to  the  packet  size  limit  is  the  Computer- 
Generated  Data  Packet,  Format  1  setup  record,  which  may  be  a  maximum  of  134,217,728 
(2^^)  bytes.  Any  packet  that  requires  more  than  524,288  bytes  may  generate  multiple 
packets  by  utilizing  the  packet  sequence  counter.  Some  packet  types  allow  a  single  data 
set  to  span  multiple  packets  if  the  data  set  size  or  time  does  not  fall  under  packet 
maximums.  The  specific  mechanism  allowing  packet  data  spanning  for  each  data  type  is 
described  within  that  data  type’s  section. 


Table  11-3.  Packet  Requirements 

Packet  Type 

Required 

Maximum  Packet  Size 

Computer-Generated  Data  Packet,  Format  1 
Setup  Record 

Yes 

134,217,728  bytes 

Time  Data  Packet 

Yes 

524,288  bytes 

All  other  data  type  packets  with  the  exception 
of  Computer-Generated  Data  Packet,  Format 

1  setup  record,  time  data  packets,  and 
Computer-Generated  Data  Packet,  Format  3 
recording  index  (root  index) 

No 

524,288  bytes 

Computer-Generated  Data  Packet,  Format  3 
recording  index  (root  index) 

Yes,  if  recording 
events  are  enabled. 
No,  if  recording 
events  are  disabled. 

524,288  bytes 
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d.  (Reserved) 

e.  All  packets  that  are  generated  shall  contain  data.  Filler  only,  idle  (as  defined  by  medium 
or  interface)  only,  or  empty  packets  shall  not  be  allowed. 

f.  All  reserved  bit  fields  in  packet  headers  or  CSDWs  shall  be  set  to  zero  (0x0). 

g.  (Reserved) 

h.  Once  version  bits  and  packet  structure  bits  have  been  used  to  indicate  a  value  or  setting 
for  each  data  type  and  its  associated  channel,  they  shall  not  change  for  that  data  type  and 
its  associated  channel  within  the  operational  session  (e.g.,  recording). 


11.2.1.1  Packet  Header 

The  length  of  the  packet  header  is  fixed  at  24  bytes  (192  bits).  The  packet  header  is 
mandatory  and  shall  consist  of  ten  fields,  positioned  contiguously  as  shown  in  Table  11-2  and 
defined  below. 


a.  Packet  Sync  Pattern.  These  2  bytes  contain  a  static  sync  value  for  every  packet.  The 
packet  sync  pattern  value  shall  be  0xEB25. 

b.  Channel  ID.  These  2  bytes  contain  a  value  representing  the  packet  channel  ID.  All 
channels  in  a  system  must  have  a  unique  channel  ID  for  each  data  source. 

(1)  Multiplexer  Source  ID.  In  a  distributed  multiplexer  system,  a  multiplexer  source  ID 
is  used  to  discern  each  multiplexer  in  the  system.  The  setup  record  shall  contain  a 
“Number  of  Source  Bits”  recorder  attribute  (R-x\NSB)  to  specify  the  number  of 
msbs  (from  the  channel  ID)  that  distinguish  the  multiplexer  source  ID.  The 
remaining  Isbs  of  the  channel  ID  field  shall  be  the  channel  ID  for  each  data  source 
acquired  by  the  multiplexer. 

(2)  Reserved  Channel  ID.  Channel  ID  0x0000  is  reserved,  and  as  of  106-17  is  used  to 
insert  only  the  Computer-Generated  Data  Packet,  Format  1  setup  record(s)  or  the 
Computer-Generated  Data  Packet,  Format  4  Streaming  Configuration  records  into 
the  composite  data  stream. 

(3)  Available  Channel  IDs.  All  values  not  comprising  the  reserved  channel  ID  are 
available.  As  of  106-13,  when  Computer- Generated  Data  Packet,  Formats  0,  2,  and 
3  reside  in  a  channel  with  ID  OxOOOI-OxFFFF,  only  one  packet  type  shall  exist  per 
channel  ID. 

c.  Packet  Length.  These  4  bytes  contain  a  value  representing  the  length  of  the  entire  packet. 
The  value  shall  be  in  bytes  and  is  always  a  multiple  of  four  (bit  1  and  bit  0  shall  always 
be  zero).  This  packet  length  includes  the  packet  header,  packet  secondary  header  (if 
enabled),  channel-specific  data,  intra-packet  headers  (IPHs),  data,  filler,  and  data 
checksum. 

d.  Data  Length.  These  4  bytes  contain  a  value  representing  the  valid  data  length  within  the 
packet.  This  value  shall  be  represented  in  bytes.  Valid  data  length  includes  channel- 
specific  data,  IPDHs,  intra-packet  time  stamp(s)  (IPTS),  and  data  but  does  not  include 
packet  trailer  filler  and  data  checksum. 
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e.  Data  Type  Version.  This  byte  contains  a  value  at  or  below  the  release  version  of  the 
standard  applied  to  the  data  types  in  Table  11-4.  The  value  shall  be  represented  by  the 
following  bit  patterns. 


0x00  =  Reserved 

0x01  =  Initial  Release  (Range  Commanders  Council  [RCC]  106-04) 

0x02  =  RCC  106-05 

0x03  =  RCC  106-07 

0x04  =  RCC  106-09 

0x05  =  RCC  106-11 

0x06  =  RCC  106-13 

0x07  =  RCC  106-15 

0x08  =  RCC  106-17 

0x09  through  OxFF  =  Reserved 


Note:  References  to  RCC  106-04  through  RCC  106-15  refer  to  Chapter  10,  while  RCC 
106-17  onward  refer  to  Chapter  11. 


Table  11-4.  Data  Type  Names  and  Descriptions 

Packet 

Header 

Value 

Data  Type  Name 

Data  Type  Description 

Current 
Data  Type 
Version 

0x00 

Computer-Generated  Data,  Format  0 

User-Defined 

0x06 

0x01 

Computer-Generated  Data,  Format  1 

Setup  Record 

0x08 

0x02 

Computer-Generated  Data,  Format  2 

Recording  Events 

0x06 

0x03 

Computer-Generated  Data,  Format  3 

Recording  Index 

0x06 

0x04 

Computer-Generated  Data,  Format  4 

Streaming  Configuration 
Records 

0x08 

0x05  -  0x07 

Computer-Generated  Data,  Format  5- 
Format  7 

Reserved  for  future  use 

0x06 

0x08 

PCM  Data,  Format  0 

Reserved  for  future  use 

0x06 

0x09 

PCM  Data,  Format  1 

Chapter  4  or  8 

0x06 

OxOA  -  OxOF 

PCM  Data,  Format  2  -  Format  7 

Reserved  for  future  use 

0x06 

0x10 

Time  Data,  Format  0 

Reserved  for  future  use 

0x06 

,0x11 

Time  Data,  Format  1 

RCC/Global  Positioning 
System  (GPS)/Relative 
Time  Counter  (RTC) 

0x06 

0x12 

Time  Data,  Format  2 

Network  Time 

0x08 

0x13-0x17 

Time  Data,  Format  2-Format  7 

Reserved  for  future  use 

0x06 

0x18 

MIL-STD-1553  Data,  Format  0 

Reserved  for  future  use 

0x06 

0x19 

MIL-STD-1553  Data,  Format  1 

MIL-STD-I553B  Data 

0x06 

OxlA 

MIL-STD-1553  Data,  Format  2 

I6PPI94  Bus 

0x06 

OxlB-OxlF 

MIL-STD-1553  Data,  Format  3- 
Format  7 

Reserved  for  future  use 

0x06 

0x20 

Analog  Data,  Format  0 

Reserved  for  future  use 

0x06 

0x21 

Analog  Data,  Format  1 

Analog  Data 

0x06 
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Table  11-4.  Data  Type  Names  and  Descriptions 

Packet 

Header 

Value 

Data  Type  Name 

Data  Type  Description 

Current 
Data  Type 
Version 

0x22-0x27 

Analog  Data,  Format  2-Format  7 

Reserved  for  future  use 

0x06 

0x28 

Discrete  Data,  Format  0 

Reserved  for  future  use 

0x06 

0x29 

Diserete  Data,  Format  1 

Diserete  Data 

0x06 

0x2A-0x2F 

Diserete  Data,  Format  2-Format  7 

Reserved  for  future  use 

0x06 

0x30 

Message  Data,  Format  0 

Generic  Message  Data 

0x06 

0x31-0x37 

Message  Data,  Format  1 -Format  7 

Reserved  for  future  use 

0x06 

0x38 

ARINC-429  Data,  Format  0 

ARINC-429  Data 

0x06 

0x39-  0x3F 

ARINC-429  Data,  Format  1 -Format  7 

Reserved  for  future  use 

0x06 

0x40 

Video  Data,  Format  0 

MPEG-2/H.264  Video 

0x06 

0x41 

Video  Data,  Format  1 

ISO  13818-1  MPEG-2 

0x06 

0x42 

Video  Data,  Format  2 

ISO  14496-10  MPEG-4 
Part  10  AVC/ITU  H.264 

0x06 

0x43 

Video  Data,  Format  3 

MJPEG 

0x07 

0x44 

Video  Data,  Format  4 

MJPEG-2000 

0x07 

0x45-0x47 

Video  Data,  Format  3-Format  7 

Reserved  for  future  use 

0x06 

0x48 

Image  Data,  Format  0 

Image  Data 

0x06 

0x49 

Image  Data,  Format  1 

Still  Imagery 

0x06 

0x4A- 

Image  Data,  Format  2 

Dynamie  Imagery 

0x06 

0x4B-0x4F 

Image  Data,  Format  3-Format  7 

Reserved  for  future  use 

0x06 

0x50 

UART  Data,  Format  0 

UART  Data 

0x06 

0x51-0x57 

UART  Data,  Format  1 -Format  7 

Reserved  for  future  use 

0x06 

0x58 

IEEE  1394  Data,  Format  0 

IEEE  1394  Transaetion 

0x06 

0x59 

IEEE  1394  Data,  Format  1 

IEEE  1394  Physieal 

Eayer 

0x06 

Ox5A-Ox5F 

IEEE  1394  Data,  Format  2-Format  7 

Reserved  for  future  use 

0x06 

0x60 

Parallel  Data,  Format  0 

Parallel  Data 

0x06 

0x61-0x67 

Parallel  Data,  Format  1 -Format  7 

Reserved  for  future  use 

0x06 

0x68 

Ethernet  Data,  Format  0 

Ethernet  Data 

0x07 

0x69 

Ethernet  Data,  Format  1 

Ethernet  UDP  Payload 

0x06 

0x6A-0x6F 

Ethernet  Data,  Format  2-Format  7 

Reserved  for  future  use 

0x06 

0x70 

TSPFCTS  Data,  Format  0 

GPS  NMEA-RTCM 

0x06 

0x71 

TSPFCTS  Data,  Format  1 

EAG  ACMI 

0x06 

0x72 

TSPFCTS  Data,  Format  2 

ACTTS 

0x06 

0x73-  0x77 

TSPFCTS  Data,  Format  3-Format  7 

Reserved  for  future  use 

0x06 

0x78 

Controller  Area  Network  Bus 

CAN  Bus 

0x06 

0x79 

Fibre  Channel  Data,  Format  0 

Eibre  Channel  Data 

0x07 

0x7A 

Fibre  Channel  Data,  Format  1 

Eibre  Channel  Data 

0x08 

0x7B  -  0x80 

Fibre  Channel  Data,  Formats  2-7 

Reserved  for  future  use 

0x08 
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f.  Sequence  Number.  This  byte  contains  a  value  representing  the  packet  sequence  number 
for  each  channel  ID.  This  is  simply  a  counter  that  increments  by  n  -i-  0x01  to  OxFF  for 
every  packet  transferred  from  a  particular  channel  and  is  not  required  to  start  at  0x00  for 
the  first  occurrence  of  a  packet  for  the  channel  ID. 


NOTE^ 

The  sequence  number  counter  value  for  each 

channel  in  a  session  (e.g.,  recording)  will  repeat 

(rollover  to  0x00)  after  the  sequence  number 

counter  has  reached  OxEE. 

NOTE 


Each  channel  in  a  session  shall  have  its 
own  sequence  counter  providing  a  unique 
sequence  number  for  that  channel. 


g.  Packet  Flags.  This  byte  contains  bits  representing  information  on  the  content  and  format 

of  the  packet(s). 

Bit  7 :  Indicates  the  presence  or  absence  of  the  packet  secondary  header. 

0  =  Packet  secondary  header  is  not  present. 

1  =  Packet  secondary  header  is  present. 

Bit  6:  Indicates  the  IPTS  time  source. 

0  =  Packet  header  48-bit  RTC. 

1  =  Packet  secondary  header  time  (bit  7  must  be  I). 

Bit  5:  RTC  sync  error. 

0  =  No  RTC  sync  error. 

1  =  RTC  sync  error  has  occurred. 

Bit  4:  Indicates  the  data  overflow  error. 

0  =  No  data  overflow. 

1  =  Data  overflow  has  occurred. 

Bits  3-2:  Indicate  the  packet  secondary  header  time  format. 

00  =  Chapter  4  binary  weighted  48-bit  time  format.  The  two  Isbs  of  the  64-bit 
packet  secondary  header  time  and  IPTS  shall  be  zero-filled. 

01  =  IEEE  1588  time  format.  The  packet  secondary  header  time  and  each  IPTS 

shall  contain  a  64-bit  timestamp  represented  in  accordance  with  (lAW)  the 
time  representation  type  as  specified  by  IEEE  STD  1588-2008. '  The  32 
bits  indicating  seconds  shall  be  placed  into  the  MSEW  portion  of  the 
secondary  header  and  the  32  bits  indicating  nanoseconds  shall  be  placed 
into  the  ESEW  portion. 


'  Institute  of  Electrical  and  Electronics  Engineers.  IEEE  standard  for  a  precision  clock  synchronization  protocol  for 
networked  measurement  and  control  systems.  IEEE  1588-2008.  Geneva:  International  Electrotechnical 
Commission,  2008. 
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10  =  64-bit  binary  extended  relative  time  counter  (ERTC)  with  1 -nanosecond 

resolution.  The  counter  shall  be  derived  from  a  free -running  1 -gigahertz 
(GHz)  clock  -  similar  to  the  RTC  described  below  -  just  with  higher 
resolution.  When  this  option  is  used,  the  10-megahertz  (MHz)  RTC  shall 
be  synchronized  with  the  ERTC  (RTC  =  ERTC/ 100). 

11=  Reserved 

Bits  1-0:  Indicate  data  checksum  existence. 

00  =  No  data  checksum  present 
01  =  8-bit  data  checksum  present 
10  =  16-bit  data  checksum  present 
11=  32-bit  data  checksum  present 


h.  Data  Type.  This  byte  contains  a  value  representing  the  type  and  format  of  the  data.  All 
values  not  used  to  define  a  data  type  are  reserved  for  future  data  type  growth.  Table  11-4 
lists  the  data  types  and  their  descriptions. 


i.  Relative  Time  Counter.  These  6  bytes  contain  a  value  representing  the  10-MHz  RTC. 
This  is  a  free-running  10-MHz  binary  counter  represented  by  48  bits  that  are  common  to 
all  data  channels.  The  counter  shall  be  derived  from  a  10-MHz  internal  crystal  oscillator 
and  shall  remain  free-running  during  each  session  (e.g.,  recording). 


If  enabled,  the  applicable  data  bit  of  the  48-bit  value  of  the  packet 
secondary  time  value  shall  correspond  to  the  first  bit  of  the  data  in 
the  packet  body  (unless  it  is  defined  in  each  data  type  section). 


j.  Header  Checksum.  These  2  bytes  contain  a  value  representing  a  16-bit  arithmetic  sum  of 
all  16-bit  words  in  the  header  excluding  the  header  checksum  word. 

11.2.1 .2  Packet  Secondary  Header  (Optional) 

The  length  of  the  packet  secondary  header  is  fixed  at  12  bytes  (96  bits).  The  packet 
secondary  header  is  optional  and  when  enabled  shall  consist  of  the  three  fields,  positioned 
contiguously,  in  the  following  sequence. 

a.  Time.  These  8  b3Tes  contain  the  value  representing  time  in  the  format  indicated  by  bits  2 
and  3  of  the  packet  flags  in  Subsection  11.2.1.1  item  g.  The  secondary  header  can  be 
enabled  on  a  channel-by-channel  basis  but  all  channels  that  have  a  secondary  header  must 
use  the  same  time  source  in  bits  2-3  of  the  packet  flags. 


NOTE/% 

The  applicable  data  bit  to  which  the  48-bit  value  of  the  packet 

/r 

secondary  time  value  (if  enabled)  applies  shall  correspond  to 

r 

the  first  bit  of  the  data  in  the  packet  body  (unless  it  is  defined  in 

each  data  type  section). 

When  Chapter  4  binary  weighted  time  is  used,  time  shall  be  stored  as  shown  in  Eigure 
11-4. 
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msb 

31 

16 

15 

Isb 

0 

Micro-Seconds  Word 

Reserved 

High  Order  Time  Word 

Eow  Order  Time  Word 

Figure  11-4. 

Secondary  Header  Chapter  4  Time 

When  IEEE  1588  time  is  used  time  shall  be  stored  as  shown  in  Eigure  11-5. 

msb 

Isb 

31 

0 

Nanoseconds  Word 

Seconds  Word 

Eigure  11-5. 

Secondary  Header  IEEE  1588  Time 

When  ERTC  time  is  used  time  shall  be  stored  as  shown  in  Eigure  1 1-6. 

msb 

Isb 

31 

0 

ESEW 

MSEW 

Figure  1 1-6.  Secondary  Header  ERTC  Time 


b.  Reserved.  These  2  bytes  are  reserved  and  shall  be  zero  filled. 

c.  Secondary  Header  Checksum.  These  2  b3Tes  contain  a  value  representing  a  16-bit 
arithmetic  sum  of  all  secondary  header  bytes  excluding  the  secondary  header  checksum 
word. 

11.2.1.3  Packet  Body 

The  format  of  the  data  in  the  packet  body  is  unique  to  each  data  type.  Detailed 
descriptions  of  the  type-specific  data  formats  found  in  packet  bodies  are  described  in  subsequent 
sections  of  this  document. 

a.  Channel-Specific  Data.  Variable  in  size,  this  contains  the  contents  of  the  channel- 
specific  data  field(s)  depending  on  the  Data  Type  field  in  the  packet  header.  Channel- 
specific  data  is  mandatory  for  each  data  type  and  channel.  The  occurrence  of  channel- 
specific  data  is  once  per  packet  and  precedes  packet  channel  data. 

b.  Intra-Packet  Time  Stamp.  These  8  bytes  contain  time  in  either  48-bit  RTC  format  (plus 
16  high-order  zero  bits)  or  64-bit  format  as  specified  in  the  packet  flags  in  the  packet 
header.  The  IPTSs  are  only  mandatory  where  defined  by  the  data  formats. 

c.  Intra-Packet  Data  Header.  Variable  in  size,  this  contains  additional  time  status,  data, 
and/or  format  information  pertaining  to  the  data  items  that  follow.  The  IPDHs  are  only 
mandatory  where  defined  by  the  data  formats. 

d.  Data.  With  n  bytes,  this  contains  valid  data  from  a  particular  channel  as  defined  within 
the  data  formats  contained  within  this  standard. 
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NOTE 


The  IPTS  and  the  IPDH  are  collectively  called  the  IPH.  In  some  cases,  an 
IPH  may  only  have  a  timestamp  (zero-length  data  header),  while  in  other 
cases,  the  IPH  only  has  a  data  header  (zero-length  timestamp).  Some  data 
types  have  no  IPH.  The  IPH  requirements  are  specified  separately  for  each 
datatype. 


NOTE 


The  IPDH  presence,  once  set,  shall  be  the  same 
state  for  the  entire  session  (e.g.,  recording)  per 
each  channel 


11.2.1 .4  Packet  Trailer 

The  packet  trailer  may  contain  filler,  a  data  checksum,  both  filler  and  a  data  checksum,  or 
neither  filler  nor  a  data  checksum.  In  the  latter  case,  the  packet  trailer  has  zero  length.  The 
reason  a  packet  trailer  would  have  a  zero  length  is  best  explained  by  understanding  the  reason  for 
inserting  filler.  The  purpose  of  the  filler  is  twofold: 

a.  To  keep  all  packets  aligned  on  32-bit  boundaries  (i.e.,  make  all  packet  lengths  a  multiple 
of  4  bytes);  and 

b.  To  optionally  keep  all  packets  from  a  particular  channel  the  same  length. 

If  both  of  the  above  requirements  are  already  met  without  adding  filler,  then  filler  shall 
not  be  added. 

The  inclusion  of  the  data  checksum  is  optional  as  well  and  is  indicated  by  the  packet  flags 
setting.  When  included,  the  packet  trailer  contains  either  an  8-bit,  16-bit,  or  32-bit  data 
checksum.  Depending  on  the  packet  flags  option  selected,  the  data  checksum  is  the  arithmetic 
sum  of  all  of  the  bytes  (8  bits),  words  (16  bits),  or  long  words  (32  bits)  in  the  packet  excluding 
the  24  bytes  of  packet  header,  packet  secondary  header  (if  enabled),  and  the  data  checksum. 
Stated  another  way,  the  data  checksum  includes  everything  in  the  packet  body  plus  all  added 
filler. 

a.  Filler.  Variable  in  size,  all  filler  shall  be  set  to  0x00  or  OxFF. 

b.  8-Bit  Data  Checksum.  This  1  byte  contains  a  value  representing  an  8 -bit  arithmetic  sum 
of  the  bytes  in  the  packet.  It  is  only  inserted  if  the  packet  flag  bits  are  set  (see  Subsection 
1 1.2. 1.1  item  g). 

c.  16-Bit  Data  Checksum.  These  2  bytes  contain  a  value  representing  a  16-bit  arithmetic 
sum  of  the  words  in  the  packet.  It  is  only  inserted  if  the  packet  flag  bits  are  set 
(Subsection  11.2.1.1  item  g). 

d.  32-Bit  Data  Checksum.  These  4  bytes  contain  a  value  representing  a  32-bit  arithmetic 
sum  of  the  long  words  in  the  packet  and  is  only  inserted  if  packet  flag  bits  are  set 
(Subsection  11.2.1.1  item  g). 

11.2.2  PCM  Data  Packets 

1 1 .2.2. 1  PCM  Data  Packets  Format  0 
Reserved. 
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1 1.2. 2. 2  PCM  Data  Packets  Format  1  (Chapter  4  and  Chapter  8) 

A  packet  with  Chapter  4  or  Chapter  8  PCM  data  has  the  basic  structure  as  shown  in  Table 
11-5.  Note  that  the  width  of  the  structure  is  not  related  to  any  number  of  bits.  This  table  merely 
represents  relative  placement  of  data  in  the  packet. 


Table  11-5.  General  PCM  Data  Packet,  Format  1 

Packet  Header 

Channel-Specific  Data 

(Optional)  Intra-Packet  Time  Stamp 

(Optional)  Intra-Packet  Data  Header 

Minor  Frame  Data 

(Optional)  Intra-Packet  Time  Stamp 

(Optional)  Intra-Packet  Data  Header 

Minor  Frame  Data 

(Optional)  Intra-Packet  Time  Stamp 

(Optional)  Intra-Packet  Data  Header 

Minor  Frame  Data 

(Optional)  Intra-Packet  Time  Stamp 

(Optional)  Intra-Packet  Data  Header 

Minor  Frame  Data 

(Optional)  Intra-Packet  Time  Stamp 

(Optional)  Intra-Packet  Data  Header 

Minor  Frame  Data 

Packet  Trailer 

The  user  may  separately  enable  or  disable  word  unpacking  on  each  active  PCM  channel. 
Word  unpacking  will  force  the  Isb  of  each  word  to  be  aligned  on  a  16-bit  boundary.  High-order 
filler  bits  are  added  to  words  as  necessary  to  force  alignment. 

The  user  may  separately  enable  or  disable  frame  synchronizing  on  each  active  PCM 
channel.  This  provides  a  throughput  mode  that  will  transfer  data  to  the  packet  without  frame 
synchronization.  Throughput  mode  essentially  disables  all  setup  and  packing/unpacking  options 
for  the  packet,  and  places  data  in  the  packet  as  it  is  received. 


a.  PCM  Packet  Channel-Specific  Data.  The  packet  body  portion  of  each  PCM  packet 
begins  with  the  channel-specific  data,  which  is  formatted  as  shown  in  Figure  11-7. 


msb 

31 

30 

29 

28 

27  24 

23 

18 

17 

Isb 

0 

R 

IPH 

MA 

MI 

LOCKST 

MODE 

SYNCOFFSET 

Figure  11-7.  Pulse  Code  Modulation  Packet  Channel-Specific  Data 

Format 


•  Reserved.  Bit  3 1  is  reserved. 
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•  Intra-Packet  Header.  Bit  30  indicates  if  IPHs  (IPTS  and  IPDH)  are  inserted  before 
each  minor  frame.  The  IPHs  are  only  optional  because  of  the  mode  selection.  This 
determines  whether  IPHs  are  included  or  omitted. 


0  =  The  IPHs  are  omitted  for  throughput  mode. 

1  =  The  IPHs  are  required  for  packed  data  and  unpacked  data  modes. 

•  Major  Frame  Indicator  (MA).  Bit  29  indicates  if  the  first  word  in  the  packet  is  the 
beginning  of  a  major  frame.  This  bit  is  not  applicable  for  throughput  mode. 

0  =  The  first  word  is  not  the  beginning  of  a  major  frame. 

1  =  The  first  word  is  the  beginning  of  a  major  frame. 

•  Minor  Frame  Indicator  (MI).  Bit  28  indicates  if  the  first  word  in  the  packet  is  the 
beginning  of  a  minor  frame.  This  bit  is  not  applicable  for  throughput  mode. 

0  =  The  first  word  is  not  the  beginning  of  a  minor  frame. 

1  =  The  first  word  is  the  beginning  of  a  minor  frame. 


•  Lock  Status  (LOCKST).  Bits  27-24  indicate  the  lock  status  of  the  frame 
synchronizer.  This  bit  is  not  applicable  for  throughput  mode. 


NOTE 


Minor  Frame  Definition.  The  minor  frame  is  defined  as  the  data  structure  in 
time  sequence  from  the  beginning  of  a  minor  frame  synchronization  pattern 
to  the  beginning  of  the  next  minor  frame  synchronization  pattern.  Please 
refer  to  Chapter  4,  Subsection  4.3.2  for  minor/major  frame  definition. 


Bits  27-26:  Indicate  minor  frame  status. 

00  =  Reserved. 

01  =  Reserved. 

10  =  Minor  frame  check  (after  losing  lock). 

11=  Minor  frame  lock. 

Bits  25-24:  Indicate  major  frame  status. 

00  =  Major  frame  not  locked. 

01  =  Reserved. 

10  =  Major  frame  check  (after  losing  lock). 

11=  Major  frame  lock. 

•  Mode  (MODE).  Bits  23-18  indicate  the  data  packing  mode. 

Bits  23-22:  Reserved. 

Bit  2 1 :  Alignment  Mode. 

0  =  16-bit  alignment  mode  enabled. 

1  =  32-bit  alignment  mode  enabled. 

Bit  20:  Indicates  throughput  data  mode. 

0  =  Throughput  data  mode  not  enabled. 

1  =  Throughput  data  mode  enabled. 

Bit  19:  Indicates  packed  data  mode. 


11-13 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


0  =  Packed  data  mode  not  enabled. 

1  =  Packed  data  mode  enabled. 

Bit  18:  Indicates  unpacked  data  mode. 

0  =  Unpacked  data  mode  not  enabled. 

1  =  Unpacked  data  mode  enabled. 

•  Sync  Offset  (SYNCOFFSET).  Bits  17-0  contain  an  18-bit  binary  value  representing 
the  word  offset  into  the  major  frame  for  the  first  data  word  in  the  packet.  The  sync 
offset  is  not  applicable  for  packed  or  throughput  mode. 

b.  PCM  Packet  Body.  After  the  channel- specific  data,  the  IPHs  and  the  PCM  data  are 
inserted  in  the  packet  in  integral  numbers  of  minor  or  major  frames  unless  the  packet  is  in 
throughput  mode.  In  throughput  mode,  there  is  no  frame  or  word  alignment  to  the  packet 
data  and  no  IPHs  are  inserted  in  the  data.  In  both  packed  and  unpacked  modes,  minor 
frame  alignment  is  dependent  on  the  MODE  field  in  the  channel- specific  data.  In  16-bit 
alignment  mode,  PCM  minor  frames  begin  and  end  on  16-bit  boundaries.  In  32-bit 
alignment  mode,  PCM  minor  frames  begin  and  end  on  32-bit  boundaries.  In  either  case, 
alignment  mode  does  not  affect  the  format  of  PCM  data  words  themselves;  however, 
depending  on  perspective,  word  order  is  affected  and  a  zero-filled  data  word  may  be 
required  to  maintain  alignment. 

c.  PCM  Data  in  Unpacked  Mode.  In  unpacked  mode,  packing  is  disabled  and  each  data 
word  is  padded  with  the  number  of  filler  bits  necessary  to  align  the  first  bit  of  each  word 
with  the  next  16-bit  boundary  in  the  packet.  For  example,  4  pad  bits  are  added  to  12-bit 
words,  6  pad  bits  are  added  to  10-bit  words,  etc.  In  32-bit  alignment  mode,  a  zero-filled 
16-bit  word  is  required  to  maintain  alignment  when  an  odd  number  of  16-bit  words  exists 
in  the  minor  frame. 

Minor  frame  sync  patterns  larger  than  16  bits  are  divided  into  two  words  of  packet  data. 

If  the  sync  pattern  has  an  even  number  of  bits,  then  it  will  be  divided  in  half  and  placed  in 
two  packet  words.  For  example,  a  24-bit  sync  pattern  is  broken  into  two  12-bit  words 
with  4  bits  of  pad  in  each  word.  If  the  sync  pattern  has  an  odd  number  of  bits,  it  is 
broken  into  two  words  with  the  second  word  having  one  bit  more  of  the  sync  pattern.  For 
example,  if  the  minor  sync  pattern  is  25  bits,  then  the  first  sync  word  is  12  bits  of  sync 
pattern  plus  4  bits  of  pad,  and  the  second  sync  word  is  13  bits  of  sync  pattern  plus  3  bits 
of  pad. 

Minor  frame  sync  patterns  larger  than  32  bits  are  divided  into  (number  of  bits-i-15)/16 
words  in  16-bit  alignment  mode  or  (number  of  bits-i-31)/32  in  32-bit  alignment  mode.  If 
the  sync  word  doesn’t  fill  the  words  completely,  the  first  word  shall  contain  the  lesser 
number  of  bits  with  the  later  words  containing  one  bit  more  (in  the  manner  described 
above  in  splitting  frame  sync  pattern  words  into  two  words).  For  example,  a  35-bit  sync 
word  shall  be  split  into  ll-i- 12-1-1 2-bit  words  in  16-bit  alignment  mode,  or  into  17-i-18-bit 
words  in  32-bit  alignment  mode. 

Given  PCM  frames  with  a  24-bit  minor  sync  pattern  and  n  data  words  where  the  bit- 
lengths  of  data  words  1,  2,  and  3  are  12,  16,  and  8  respectively,  the  resultant  16-bit 
alignment  mode  PCM  packets  are  as  shown  in  Table  11-6.  Given  PCM  frames  with  a  24- 
bit  minor  sync  pattern  and  n  data  words  where  the  bit-lengths  of  data  words  1,  2,  3,  and  4 
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are  12,  16,  8,  and  10  respectively,  the  resultant  32-bit  alignment  mode  PCM  packets  are 
as  shown  in  Table  11-7, 


Table  11-6. 


PCM  Data-Unpacked  (16-Bit  Alignment 
Mode)  Sample  Packet 


msb 

15 


Isb 

0 


Packet  Header 


Channel-Specific  Data  (Bits  15-0) 


Channel-Specific  Data  (Bits  31-16) 


Intra-Packet  Time  Stamp  (Bits  15-0) 


Intra-Packet  Time  Stamp  (Bits  31-16) 


Intra-Packet  Time  Stamp  (Bits  47-32) 


Intra-Packet  Time  Stamp  (Bits  63-48) 


Intra-Packet  Data  Header  (Bits  15-0) 


4  Bits  Pad 


12  Bits  Sync  (Bits  23-12) 


4  Bits  Pad 


12  Bits  Sync  (Bits  11-0) 


4  Bits  Pad 


12  Bits  Word  1  Data 


16  Bits  Word  2  Data 


8  Bits  Pad 


8Bits  Word  3  Data 


Word  N  Data  Bits  -i-  Pad  if  Needed 
Intra-Packet  Time  Stamp  (Bits  15-0) 
Intra-Packet  Time  Stamp  (Bits  31-16) 
Intra-Packet  Time  Stamp  (Bits  47-32) 
Intra-Packet  Time  Stamp  (Bits  63-48) 
Intra-Packet  Data  Header  (Bits  15-0) 


Repeat  for  each  minor  frame. 


Packet  Trailer 


Table  11-7.  PCM  Data-Unpacked  (32-Bit  Alignment 
Mode)  Sample  Packet 

msb  Isb 

\5 _ 0 

Packet  Header _ 

_ Channel-Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  (Bits  15-0) 

Intra-Packet  Time  Stamp  (Bits  31-16) 

Intra-Packet  Time  Stamp  (Bits  47-32) 

Intra-Packet  Time  Stamp  (Bits  63-48) 
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Intra-Packet  Data  Header  (Bits  15-0) 


Intra-Packet  Data  Header  (Bits  31-16) 


4  Bits  Pad 

12  Bits  Sync  (Bits  11-0) 

4  Bits  Pad 

12  Bits  Sync  (Bits  23-12) 

16  Bits  Word  2  Data 


4  Bits  Pad 

12  Bits  Word  1  Data 

6  Bits  Pad 

10  Bits  Word  4  Data 

8  Bits  Pad 

8  Bits  Word  3  Data 

Word  N  Data  Bits  -i-  Pad  If  Needed 
Intra-Packet  Time  Stamp  (Bits  15-0) 
Intra-Packet  Time  Stamp  (Bits  31-16) 
Intra-Packet  Time  Stamp  (Bits  47-32) 
Intra-Packet  Time  Stamp  (Bits  63-48) 
Intra-Packet  Data  Header  (Bits  15-0) 

Intra-Packet  Data  Header  (Bits  31-16) 


Repeat  for  each  minor  frame. 


Packet  Trailer 


d.  PCM  Data  in  Packed  Mode.  In  packed  mode,  packing  is  enabled  and  pad  is  not  added  to 
each  data  word;  however,  filler  bits  may  be  required  to  maintain  minor  frame  alignment. 
The  number  of  filler  bits  is  dependent  on  the  alignment  mode,  where  N  is  either  16  or  32. 
If  the  number  of  bits  in  the  minor  frame  is  not  an  integer  multiple  of  N,  then  Y  pad  bits 
will  be  added  to  the  end  of  each  minor  frame  of  bit  length  L.  Either  Y  =  N-MOD(L,N), 
or  N  minus  the  integer  remainder  when  L  is  divided  by  N.  In  packed  mode,  the  PCM 
stream  is  minor-frame  synchronized  so  the  first  data  bit  in  the  packet  is  the  first  data  bit 
of  a  minor  frame.  If  X  =  N  -  Y  when  N  is  16-bit  alignment  mode,  then  the  resultant 
PCM  packets  are  as  shown  in  Table  11-8.  Table  11-9  shows  the  resultant  PCM  packets 
for  32-bit  alignment  mode. 

Table  11-8.  PCM  Data-Packed  (16-Bit  Alignment  Mode) 

Sample  Packet 

msb  Isb 

J5 _ 0_ 

Packet  Header _ 

_ Channel-Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  (Bits  15-0) 

Intra-Packet  Time  Stamp  (Bits  31-16) 

Intra-Packet  Time  Stamp  (Bits  47-32) 

Intra-Packet  Time  Stamp  (Bits  63-48) 

Intra-Packet  Data  Header  (Bits  15-0) 
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Data  (Bits  15-0) 

Data  (Bits  31-16) 

Data  (Bits  47-32) 

Y  Filler  Bits  X  Data  Bits 

Intra-Packet  Time  Stamp  (Bits  15-0) 

Intra-Packet  Time  Stamp  (Bits  31-16) 

Intra-Packet  Time  Stamp  (Bits  47-32) 

Intra-Packet  Time  Stamp  (Bits  63-48) 

Intra-Packet  Data  Header  (Bits  15-0) 

Repeat  for  each  minor  frame. 

Packet  Trailer 

Table  11-9.  PCM  Data-Packed  (32-Bit  Alignment  Mode) 

Sample  Packet 

msb  Isb 

15  0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

Intra-Packet  Time  Stamp  (Bits  15-0) 

Intra-Packet  Time  Stamp  (Bits  31-16) 

Intra-Packet  Time  Stamp  (Bits  47-32) 

Intra-Packet  Time  Stamp  (Bits  63-48) 

Intra-Packet  Data  Header  (Bits  15-0) 

Intra-Packet  Data  Header  (Bits  31-16) 

Data  Word  2 

Data  Word  1 

Data  Word  4 

Data  Word  3 

Filler  Bits  X  Data  Bits 

16  Filler  Bits  (If  Required  to  Maintain  32-Bit  Alignment) 

Intra-Packet  Time  Stamp  (Bits  15-0) 

Intra-Packet  Time  Stamp  (Bits  31-16) 

Intra-Packet  Time  Stamp  (Bits  47-32) 

Intra-Packet  Time  Stamp  (Bits  63-48) 

Intra-Packet  Data  Header  (Bits  15-0) 

Intra-Packet  Data  Header  (Bits  31-16) 

Repeat  for  each  minor  frame. 
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Packet  Trailer 


e.  PCM  Data  in  Throughput  Mode.  In  throughput  mode,  the  PCM  data  are  not  frame 
synchronized  so  the  first  data  bit  in  the  packet  can  be  any  bit  in  the  major  frame.  The 
resultant  PCM  packets  are  as  shown  in  Table  11-10  and  Table  11-11. 

Table  11-10.  PCM  Data-Throughput  (16-Bit  Alignment 
Mode)  Sample  Packet 

msb  Isb 

_ 0_ 

Packet  Header _ 

_ Channel-Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

Data  (Bits  15-0) _ 

Data  (Bits  31-16) _ 

Data  (Bits  47-32) 


Packet  Trailer 


Table  11-11.  PCM  Data-Throughput  (32-Bit  Alignment 
Mode)  Sample  Packet 

msb  Isb 

15 _ 0 

Packet  Header _ 

_ Channel-Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

PCM  Stream  Bits  17-32 
PCM  Stream  Bits  1-16 
PCM  Stream  Bits  49-64 
PCM  Stream  Bits  33-48 


Packet  Trailer 


f.  PCM  Data  Word  Order  in  32-Bit  Alignment  Mode.  When  acquitting  data  in  32-bit 

alignment  mode,  the  resultant  data  word  ordering  will  differ  from  16-bit  alignment  mode. 
The  serial  PCM  data  stream  is  shifted  into  32-bit  words  from  right  to  left,  with  bit  31  on 
the  left,  bit  0  on  the  right,  and  addresses  ascending  from  top  to  bottom.  Word  order  is 
affected  depending  on  the  reader’s  addressing  perspective.  For  example,  16-bit  data 
words  when  addressed  as  32-bit  words  appear  in  order  when  read  from  left  to  right  and 
top  to  bottom;  however,  when  addressed  as  16-bit  words,  each  pair  of  data  words  will 
appear  swapped.  Figure  11-8  and  Figure  11-9  depict  the  anomaly  of  perspective. 


11-18 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


msb  Isb 

31  16  15  0 

Address 

Byte  3  Byte  2 

Byte  1  Byte  0 

Data  Word  1 

Data  Word  2 

0 

Data  Word  3 

Data  Word  4 

1 

Data  Word  N-1 

Data  Word  N 

(N/2)-l 

Figure  1 1-8.  32-Bit  Alignment  Mode  Example,  16-Bit  Data  Words  (32- 

Bit  Word  Addressing) 


Figure 


msb  Isb 

15  0 

Address 

Byte  1  Byte  0 

Data  Word  2 

0 

Data  Word  1 

1 

Data  Word  4 

2 

Data  Word  3 

3 

Data  Word  N-1 

N-1 

1-9.  32-Bit  Alignment  Mode  Example,  16-Bit  Data  Words  (16- 
Bit  Word  Addressing) 


g.  PCM  Intra-Paeket  Header.  When  aequiring  data  in  paeked  or  unpaeked  mode,  all  PCM 
minor  frames  shall  include  an  IPH  containing  a  64-bit  IPTS  and  a  16-  or  32-bit  IPDH,  as 
indicated  by  MODE  in  the  channel- specific  data.  This  header  is  inserted  immediately 
before  the  minor  frame  sync  pattern.  Depending  on  alignment  mode,  the  length  of  the 
IPH  is  either  10  or  12  bytes  (80  or  96  bits)  positioned  contiguously,  as  depicted  in  Figure 
1 1-10.  In  16-bit  alignment  mode,  the  IPDH  length  is  fixed  at  2  bytes.  A  32-bit  alignment 
mode  requires  a  4-byte  IPDH,  and  the  two  most  significant  bytes  are  zero-filled. 


msb 

Isb 

31 

16 

15 

12 

11 

0 

Time  (FSFW) 

Time  (MSFW) 

Zero  Filled 

FOCKST 

RESERVED 

Figure  1 1-10.  Pulse  Code  Modulation  Intra-Packet  Header 


•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  PCM  minor 
frame.  This  time  stamp  is  not  applicable  for  throughput  mode.  First  long  word  bits 
and  second  long  word  bits  indicate  the  following  values: 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  of  the  minor  frame  with 
bits  31  to  16  in  the  second  long  word  zero-filled;  or 

o  Absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item 
g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  of  the  minor  frame. 
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•  Intra-Packet  Data  Header 

o  32-Bit  Alignment  (32-Bit  Alignment  mode  ONLY).  Bits  31-16  are  zero- 
filled. 

o  Lock  Status  (LOCKST).  Bits  15-12  indicate  the  lock  status  of  the  frame 
synchronizer  for  each  minor  frame. 

o  Bits  15-14:  Indicates  minor  frame  status. 

00  =  Reserved 
01  =  Reserved 

10  =  Minor  frame  check  (after  losing  lock) 

11=  Minor  frame  lock 

o  Bits  13-12:  Indicates  major  frame  status. 

00  =  Major  frame  not  locked 
01  =  Reserved 

10  =  Major  frame  check  (after  losing  lock) 

11=  Major  frame  lock 

o  Reserved.  Bits  11-0  are  reserved. 


11.2.3  Time  Data  Packets 


1 1 .2.3.1  Time  Data  Packets,  Format  0.  Reserved. 

1 1 .2.3.2  Time  Data  Packets,  Format  1  (IRIG/GPS/RTC) 

Time  is  treated  like  another  data  channel.  If  a  time  source  other  than  NONE  is  used 
(Figure  11-11),  the  time  packet  will  be  generated  at  a  minimum  frequency  of  1  hertz. 


msb 

31 

16 

15 

12 

11  8 

7 

4 

3 

Isb 

0 

Reserved 

ITS 

DATE 

EMT 

SRC 

Figure  11-11.  Time  Packet  Channel-Specific  Data  Format 


•  Inter-Range  Instrumentation  Group  (IRIG)  Time  Type  Formats.  The  10-MHz  RTC 
shall  be  captured  for  insertion  into  the  time  packet  data  header  lAW  IRIG  200.^ 


•  All  Non-IRIG  Time  Type  Formats.  The  10-MHz  RTC  shall  be  captured  for  insertion 
into  the  time  packet  data  header  consistent  with  the  resolution  with  the  time  packet 
body  format  (10  milliseconds  [ms]  as  measured  by  the  10-MHz  RTC). 


A  time  data  packet  shall  be  the  first  dynamic  data  packet  at  the  start 
of  each  session.  Only  static  Computer-Generated  Data,  Format  1 
packets  may  precede  the  first  time  data  packet. 


^  Range  Commanders  Council.  ‘TRIG  Serial  Time  Code  Formats.”  RCC  200-16.  August  2016.  Maybe 
superseded  by  update.  Retrieved  27  April  2017.  Available  at  http://www.wsmr.armv.mil/RCCsite/Documents/200- 
16  IRIG  Serial  Time  Code  Formats/. 
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If  the  time  data  packet  source  is  None,  at  least 
one  time  data  packet  is  required  lAW  the 
previous  note. 


A  packet  with  time  data  has  the  basic  structure  shown  in  Table  11-12.  Note  that  the 
width  of  the  structure  is  not  related  to  any  number  of  bits.  This  drawing  is  merely  to  represent 
relative  placement  of  data  in  the  packet.  Time  packets  do  not  have  IPHs. 

Table  11-12.  General  Time  Data  Packet,  Format  1 

Packet  Header 

Channel-Specific  Data _ 

Time  Data 
Packet  Trailer 


a.  Time  Packet  Channel-Specific  Data.  The  packet  body  portion  of  each  time  data  packet 
begins  with  a  CSDW  formatted  as  shown  in  Figure  11-11. 

•  Reserved.  Bits  31-16  are  reserved. 

•  IRIG  Time  Source  (ITS).  Bits  15-12  provide  dynamic  information  regarding  the 
source  of  time  for  an  internal  IRIG  time  code  generator  (TCG)  when  FMT  is  IRIG-A, 
B,  or  G.  The  ITS  bits  can  toggle  depending  upon  quality/validity  of  sources. 

0000  =  IRIG  TCG  freewheeling  (no  or  loss  of  time  source) 

0001  =  IRIG  TCG  freewheeling  from  .TIME  command 
0010  =  IRIG  TCG  freewheeling  from  RMM  time 
0011=  IRIG  TCG  locked  to  external  IRIG  time  signal 
0100  =  IRIG  TCG  locked  to  external  GPS 

0101  =  IRIG  TCG  locked  to  external  Network  Time  Protocol  (NTP) 

01 10  =  IRIG  TCG  locked  to  external  Precision  Time  Protocol  (PTP) 

0111  =  IRIG  TCG  locked  to  external  embedded  time  from  input  track/channel 
such  as  PCM  or  MIL-STD-1553 
1000- 1111  =  Reserved 

•  Date  (DATE).  Bits  11-8  indicate  the  date  format.  All  bit  patterns  not  used  to  define  a 
date  format  type  are  reserved  for  future  growth. 

o  Bits  11-10:  Reserved. 

o  Bit  9:  Indicates  date  format. 

0  =  IRIG  day  available  (Eigure  11-12) 

1  =  Month  and  year  available  (Eigure  11-13) 


11-21 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


msb  Isb 

15  14  12  11  8  7  4  3  0 

0 

TSn 

Sn 

Hmn 

Tmn 

0 

0 

THn 

Hn 

0  TMn 

Mn 

0 

0 

0  0 

0  0  HDn 

TDn 

Dn 

Figure  11-12.  Time  Data-Packet  Format,  Day  Format 


msb  Isb 

15  14  12  11  8  7  4  3  0 
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TSn 

Sn 

Hmn 

Tmn 

0 
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THn 

Hn 

0  TMn 

Mn 

0 

0 

0  Ton 

On 

TDn 

Dn 

0 

0 

OYn 

HYn 

TYn 

Yn 

Figure  11-13.  Time  Data-Packet  Format,  Day,  Month,  and  Year  Format 


o  Bit  8:  Indicates  if  this  is  a  leap  year. 

0  =  Not  a  leap  year 
1  =  Is  a  leap  year 

•  Time  Format  (FMT).  Bits  7-4  indicate  the  time  data  packet  format. 

0x0  =  IRIG-B 
0x1  =  IRIG- A 
0x2  =  IRIG-G 
0x3  =  Real-Time  Clock 

0x4  =  Universal  Coordinated  Time  (UTC)  time  from  GPS 

0x5  =  Native  GPS  Time 

0x6  -  OxE  =  Reserved 

OxF  =  NONE  (time  packet  payload  invalid) 


•  Time  Source  (SRC).  Bits  3-0  indicate  the  source  of  the  time  in  the  payload  of  each 
time  packet. 

0x0  =  Internal  (time  derived  from  a  clock  in  the  recorder) 

0x1  =  External  (time  derived  from  a  clock  not  in  the  recorder) 

0x2  =  Internal  from  RMM  (time  derived  from  the  clock  in  the  RMM) 

0x3  -  OxE  =  Reserved 
OxE  =  None 


NOTE 


If  the  time  source  is  external  (0x1)  and  lock  on  the  external  source  is  lost  then 
the  time  source  shall  indicate  Internal  (0x0).  Once  lock  on  the  external  time 
source  is  regained,  time  source  shall  once  again  indicate  external  (0x1). 


b.  Time  Packet  Body.  After  the  CSDW,  the  time  data  words  are  inserted  in  the  packet  in 
binary-coded  decimal  format  as  shown  in  Eigure  11-12  and  Eigure  11-13  (units  of 
measure  presented  in  Table  11-13). 
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Table  11-13.  Units  of  Measure 

Tmn 

Tens  of  ms 

TDn 

Tens  of  days 

Hmn 

Hundreds  of  ms 

HDn 

Hundreds  of  days 

Sn 

Units  of  seconds 

On 

Units  of  months 

TSn 

Tens  of  Seconds 

TOn 

Tens  of  months 

Mn 

Units  of  minutes 

Yn 

Units  of  years 

TMn 

Tens  of  minutes 

TYn 

Tens  of  years 

Hn 

Units  of  hours 

HYn 

Hundreds  of  years 

THn 

Tens  of  hours 

OYn 

Thousands  of  years 

Dn 

Units  of  days 

0 

Always  zero 

1 1 .2.3.3  Time  Data  Packets,  Format  2  (Network  Time) 

The  Format  2  Network  Time  packet  data  type  is  used  to  extract  and  encapsulate  absolute 
time  from  NTP  or  IEEE- 1588  PTP  and  time  tag  it  with  the  RTC.  The  Eormat  2  Network  Time 
packet  will  be  generated  at  a  minimum  frequency  of  1  hertz  unless  it  is  recorded  at  the  raw 
network  rate  of  the  NTP  or  PTP  frames. 


The  NTP  is  referenced  in  UTC  time  with  an  epoch  of  January  1,  1900.  The  NTP  time 
includes  leap  seconds. 


The  PTP  is  referenced  in  International  Atomic  Time  with  an  epoch  of  January  1,  1970. 
The  PTP  time  does  not  include  leap  seconds. 


A  time  data  packet  shall  be  the  first  dynamic  data  packet  at  the  start 
of  each  recording.  Only  static  Computer-Generated  Data,  Eormat  1 
packets  may  precede  the  first  time  data  packet  in  the  recording. 


The  Eormat  2  Network  Time  packet  has  the  basic  structure  shown  in  Table  11-14.  Note 
that  the  width  of  the  structure  is  not  related  to  any  number  of  bits.  This  drawing  is  merely  to 
represent  relative  placement  of  data  in  the  packet.  Eormat  2  Network  Time  packets  do  not  have 
IPHs. 


Table  11-14.  General  Time  Data 
Packet,  Format  1 

Packet  Header 

Channel-Specific  Data _ 

Time  Data 
Packet  Trailer 


a.  Time  Packet  Channel-Specific  Data.  The  packet  body  portion  of  each  time  data  packet 
begins  with  a  CSDW  formatted  as  shown  in  Eigure  11-14. 
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b.  msb 

Isb 

31 
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0 

Reserved 

NTE 

TS 

Figure  1 1-14.  Format  2  Network  Time  Packet  Channel-Specific  Data 

Format 


•  Reserved.  Bits  31-8  are  reserved. 

•  Network  Time  Format  (NTF).  Bits  7-4  indicate  the  time  data  packet  format. 

0x0  =  Network  Time  Protocol  Version  3  (Request  for  Comment  1305^). 

0x1  =  IEEE-1588-2002 
0x2  =  IEEE-1588-2008 
0x3  -  OxE  =  Reserved 

•  Time  Status  (TS).  Bits  3-0  indicate  the  status  of  the  network  time. 

0x0  =  Time  Not  Valid 
0x1  =  Time  Valid 
0x2  -  0xE=  Reserved 

c.  Time  Packet  Body.  After  the  CSDW,  the  time  data  is  inserted  in  the  packet  as  shown  in 
Eigure  11-15  for  NTP  and  Eigure  11-16  for  PTP. 

msb  Isb 

^1 _ 0_ 

Time  Unsigned  Seconds _ 

Time  Unsigned  Seconds  Tractions 

Eigure  11-15.  Eormat  2  Network  Time  Packet  NTP  Time  Data 


msb 

^1 _ 

Time  Unsigned  Seconds 
Time  Unsigned  Nanoseconds 

Eigure  11-16.  Eormat  2  Network  Time  Packet  PTP  Time  Data 

11.2.4  MIE-STD-1553  Packets 

11.2.4.1  MIE-STD-1553  Bus  Data  Packets,  Eormat  0. 

Reserved. 

1 1.2.4. 2  MIE-STD-1553  Bus  Data  Packets,  Eormat  1  (MIE-STD-1553B  Bus  Data) 

Data  in  the  MIE-STD-1553  bus  format  is  packetized  as  messages,  with  each  1553  bus 
transaction  recorded  as  a  message.  A  transaction  is  a  bus  controller  (BC)-to-remote  terminal 
(RT),  RT-to-BC,  or  RT-to-RT  word  sequence,  starting  with  the  command  word  and  including  all 


Isb 

0 


^  Internet  Engineering  Task  Force.  “Network  Time  Protocol  (Version  3)  Specification,  Implementation  and 
Analysis.”  RFC  1305.  March  1992.  Obsoleted  by  RFC  5905.  Retrieved  22  June  2017.  Available  at 
https://datatracker.ietf.org/doc/rfcl305/. 
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data  and  status  words  that  are  part  of  the  transaction,  or  a  mode  code  word  broadcast.  Multiple 
messages  may  be  encoded  into  the  data  portion  of  a  single  packet. 


a. 


MIL-STD-1553  Packet  Channel-Specific  Data.  The  packet  body  portion  of  each  MIL- 
STD-1553  data  packet  begins  with  a  CSDW  formatted  as  shown  in  Figure  1 1-17. 


msb 

31 

TTB 


30  29 

RESERVED 


24  23 

MSGCOUNT 


Isb 

0 


Eigure  1 1-17.  MIE-STD-1553  Packet  Channel-Specific  Data  Eormat 


•  Time  Tag  Bits  (TTB).  Bits  31-30  indicate  which  bit  of  the  MIE-STD-1553  message 
the  IPH  time  tags. 

00  =  East  bit  of  the  last  word  of  the  message 
01  =  Eirst  bit  of  the  first  word  of  the  message 

10  =  East  bit  of  the  first  (command)  word  of  the  message 

11  =  Reserved 

•  Reserved.  Bits  29-24  are  reserved. 

•  Message  Count  (MSGCOUNT).  Bits  23-0  indicate  the  binary  value  of  the  number  of 
messages  included  in  the  packet.  An  integral  number  of  complete  messages  will  be  in 
each  packet. 

b.  MIE-STD-1553  Packet  Body.  A  packet  within  MIE-STD-1553  messages  has  the  basic 
structure  shown  in  Table  11-15.  Note  that  the  width  of  the  structure  is  not  related  to  any 
number  of  bits.  This  drawing  is  merely  intended  to  represent  relative  placement  of  data 
in  the  packet. 


Table  11-15.  MIL-STD-1553  Data  Packet,  Format  1 

Basic  Layout 

Packet  Header 

Channel-Specific  Data 

Intra-Packet  Time  Stamp  for  Message  1 

Intra-Packet  Data  Header  for  Message  1 

Message  1 

Intra-Packet  Time  Stamp  for  Message  2 

Intra-Packet  Data  Header  for  Message  2 

Message  2 

Intra-Packet  Time  Stamp  for  Message  N 

Intra-Packet  Data  Header  for  Message  N 

Message  N 

Packet  Trailer 
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c.  MIL-STD-1553  Intra-Packet  Header.  After  the  channel- specific  data,  the  MIL-STD- 
1553  data  are  inserted  into  the  packet  in  messages.  Each  MIL-STD-1553  message  is 
preceded  by  an  IPH  consisting  of  an  IPTS  and  an  IPDH. 

(1)  MIL-STD-1553  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the 
MIL-STD-1553  message  as  follows. 

•  The  48-bit  RTC  that  corresponds  to  the  data  bit  indicated  in  the  MIL-STD- 
1553  channel-specific  data,  TTBs  (Subsection  1 1.2.4. 2  item  a)  with  bits  31  to 
16  in  the  second  long  word  zero-filled;  or 

•  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  data  bit 
indicated  in  the  MIL-STD-1553  channel-specific  data,  TTBs  (Subsection 
11.2.4.2  item  a). 

(2)  MIL-STD-1553  Intra-Packet  Data  Header.  The  length  of  the  IPDH  is  fixed  at  6 
bytes  (48  bits)  positioned  contiguously,  in  the  following  sequence  (Ligure  11-18). 

msb 

J5 _ 

Block  Status  Word 
Gap  Times  Word 
Length  Word _ 

Ligure  11-18.  MIL-STD-1553  Intra-Packet  Data  Header 

•  Block  Status  Word  (BSW).  Bits  15-0  contain  the  block  status  word  for  both 
the  message  type  and  any  1553  bus  protocol  errors  that  occurred  during  the 
message  transfer.  The  block  status  word  bit  definitions  are  in  Ligure  11-19. 


msb 

15 

14  13 

12 

II 

10 

9 

OO 

5 

4 

3 

Isb 

2  0 

R 

BID 

ME 

RR 

LE 

TM 

RESERVED 

LE 

SE 

WE 

RESERVED 

Ligure  1 1-19.  Block  Status  Word 


•  Reserved  (R).  Bits  15-14  are  reserved. 

•  Bus  ID  (BID).  Bit  13  indicates  the  bus  ID  for  the  message. 

0  =  Message  was  from  channel  A 
1  =  Message  was  from  channel  B 

•  Message  Error  (ME).  Bit  12  indicates  a  message  error  was 
encountered. 

0  =  No  message  error 
1  =  Message  error 

•  RT  to  RT  Transfer  (RR).  Bit  1 1  indicates  a,  RT  to  RT  transfer; 
message  begins  with  two  command  words. 

0  =  No  RT  to  RT  transfer 


Isb 

0 
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1  =  RT  to  RT  transfer 

•  Format  Error  (FE).  Bit  10  indicates  any  illegal  gap  on  the  bus  other 
than  response  timeout. 

0  =  No  format  error 
1  =  Format  error 

•  Response  Time  Out  (TM).  Bit  9  indicates  a  response  time  out 
occurred.  The  bit  is  set  if  any  of  the  status  word(s)  belonging  to  this 
message  didn’t  arrive  within  the  response  time  of  14  microseconds 
(ps)  defined  by  MIL-STD-1553B.'* 

0  =  No  response  time  out 
1  =  Response  time  out 

•  Reserved.  Bits  8-6  are  reserved. 

•  Word  Count  Error  (LE).  Bit  5  indicates  that  the  number  of  data  words 
transmitted  is  different  than  identified  in  the  command  word.  A  MIL- 
STD-1553B  status  word  with  the  busy  bit  set  to  true  will  not  cause  a 
word  count  error.  A  transmit  command  with  a  response  timeout  will 
not  cause  a  word  count  error. 

0  =  No  word  count  error 
1  =  Word  count  error 

•  Sync  Type  Error  (SE).  Bit  4  indicates  an  incorrect  sync  type  occurred. 

0  =  No  sync  type  error 
1  =  Sync  type  error 

•  Invalid  Word  Error  (WE).  Bit  3  indicates  an  invalid  word  error 
occurred.  This  includes  Manchester  decoding  errors  in  the  sync 
pattern  or  word  bits,  invalid  number  of  bits  in  the  word,  or  parity  error. 

0  =  No  invalid  word  error 
1  =  Invalid  word  error 


•  Reserved.  Bits  2-0  are  reserved. 


NOTE 


Gap  Times  (response  time):  The  gap  times  word  indicates  RT  response  times 
as  defined  by  MIL-STD-1553.  The  resolution  of  the  response  time  shall  be  in 
tenths  of  ps.  A  maximum  of  two  response  time  words  can  exist.  Messages  of 
RT-to-RT  type  shall  have  two  response  time  words  if  both  terminals  respond; 
all  other  messages  will  have  one  response  time  word,  or  none  for  broadcast 
type  messages  or  messages  with  no  RT  response. 


•  Gap  Times  Word.  Bits  15-0  indicate  the  number  of  tenths  of  ps  in  length  of 
the  internal  gaps  within  a  single  transaction.  For  most  messages,  only  GAPl 


Department  of  Defense.  “Aircraft  Internal  Time  Division  Command/Response  Multiplex  Data  Bus.”  MIL-STD- 
1553B.  15  January  1996.  May  be  superseded  by  update.  Retrieved  27  April  2017.  Available  at 
http://quicksearch.dla.mil/qsDocDetails.aspx7ident  number=36973. 


11-27 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


is  meaningful.  It  measures  the  time  between  the  command  or  data  word  and 
the  first  (and  only)  status  word  in  the  message.  For  RT-to-RT  messages, 
GAP2  measures  the  time  between  the  last  data  word  and  the  second  status 
word.  The  gap  times  word  bit  definitions  are  as  shown  in  Figure  11-20. 


msb 

Isb 

15 

8 

7 

0 

GAP2 

GAPl 

Figure  1 1-20.  Gap  Times  Word 


NOTE 


r 


Gap  measurements  shall  be  made  lAW  MIL-STD-1553  response 
time  measurements  from  the  mid-bit  zero  crossing  of  the  parity  bit  of 
the  last  word  to  the  mid-zero  crossing  of  the  sync  of  the  status  word. 


•  Length  Word.  Bits  15-0  contain  the  length  of  the  message,  which  is  the  total 
number  of  bytes  in  the  message.  A  message  consists  of  command  words,  data 
words,  and  status  words. 


d.  Packet  Format.  Unless  an  error  occurred,  as  indicated  by  one  of  the  error  flags  in  the 
block  status  word,  the  first  word  following  the  length  word  shall  always  be  a  command 
word.  The  resultant  packets  have  the  format  shown  in  Table  11-16. 


Table  11-16.  MIL-STD-1553  Data  Packet,  Format  1 


msb 

Isb 

15 

0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 


_ Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  for  Msg  I  (Bits  15-0) 
Intra-Packet  Time  Stamp  for  Msg  I  (Bits  31-16) 
Intra-Packet  Time  Stamp  for  Msg  I  (Bits  47-32) 
Intra-Packet  Time  Stamp  for  Msg  I  (Bits  63-48) 
Intra-Packet  Data  Header  for  Msg  I  (Bits  15-0) 
Intra-Packet  Data  Header  for  Msg  I  (Bits  31-16) 
Intra-Packet  Data  Header  for  Msg  1  (Bits  47-32) 
Command  Word 

Command,  Status,  or  Data  Word _ 

Data  or  Status  Word 


Data  or  Status  Word 

Intra-Packet  Time  Stamp  for  Msg  2  (Bits  15-0) 
Intra-Packet  Time  Stamp  for  Msg  2  (Bits  31-16) 
Intra-Packet  Time  Stamp  for  Msg  2  (Bits  47-32) 
Intra-Packet  Time  Stamp  for  Msg  2  (Bits  63-48) 
Intra-Packet  Data  Header  for  Msg  2  (Bits  15-0) 
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Intra-Packet  Data  Header  for  Msg  2  (Bits  31-16) 

Intra-Packet  Data  Header  for  Msg  2  (Bits  47-32) 

Command  Word 

Command,  Status,  or  Data  Word 

Data  or  Status  Word 

Data  or  Status  Word 

Intra-Packet  Time  Stamp  for  Msg  N  (Bits  15-0) 

Intra-Packet  Time  Stamp  for  Msg  N  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Msg  N  (Bits  47-32) 

Intra-Packet  Time  Stamp  for  Msg  N  (Bits  63-48) 

Intra-Packet  Data  Header  for  Msg  N  (Bits  15-0) 

Intra-Packet  Data  Header  for  Msg  N  (Bits  31-16) 

Intra-Packet  Data  Header  for  Msg  N  (Bits  47-32) 

Command  Word 

Command  or  Data  Word 

Data  or  Status  Word 

Data  or  Status  Word 

Packet  Trailer 

11.2.4.3  MIL-STD-1553  Bus  Data  Packets,  Format  2  (Bus  16PP194  Weapons  Bus  Data) 

This  data  type  provides  packetization  for  the  F-16  MIL-STD-1553  weapons  multiplex 
bus  as  defined  in  document  16PP362B.^  A  16PP194  transaction  consists  of  six  each  32-bit 
words  consisting  of  a  16PP194  COMMAND  (1),  COMMAND  (1)  ECHO,  COMMAND  (2), 
COMMAND  (3)  GO/NOGO,  COMMAND  (4)  GO/NOGO,  and  STATUS  as  illustrated  in  Figure 
11-21.  Multiple  transactions  may  be  encoded  into  the  data  portion  of  a  single  packet. 


TX 


(1) 

(2) 

(4) 

(5) 

COMMAND  (1) 

COMMAND  (2) 

COMMAND  (3) 
GO/NO  GO 

COMMAND  (4) 
GO/NO  GO 

RX 


(3) 


COMMAND  (1) 
ECHO 


(6) 


STATUS 


Figure  11-21.  16PP194  Message  Transaction 


a.  MIL-STD-1553  16PP194  Packet  Channel-Specific  Data  Word.  The  packet  body  portion 
of  each  16PP  MIL-STD-1553  data  packet  begins  with  a  CSDW  formatted  as  shown  in 


^  Lockheed  Martin  Corporation.  “Advanced  Weapons  Multiplex  Data  Bus.”  8  June  2010.  May  be  superseded  by 
update.  Retrieved  27  April  2017.  Available  to  RCC  members  with  Private  Portal  access  at 
https://wsdmext.wsmr.armv.mil/site/rccpri/Limited  Distribution  References/1 6PP362B.pdf. 
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Figure  11-22.  Bits  31-0  indicate  the  binary  value  of  the  number  of  messages  included  in 
the  packet.  An  integral  number  of  complete  transaction  messages  will  be  in  each  packet. 


Isb 
_0 

MSGCOUNT _ 

Figure  11-22.  Military  Standard  1553  16PP194  Packet  Channel-Specific 

Data  Format 


msb 

31 


b.  MIL-STD-1553  16PP194  Packet  Body.  A  packet  with  n  MIL-STD- 1553  16PP 194 
transactions  has  the  basic  structure  shown  in  Table  11-17  below.  This  drawing  is  merely 
to  represent  relative  placement  of  data  in  the  packet. 


Table  11-17.  MIL-STD-1553  16PP194  Data  Packet  Basic  Layout 


msb 

31 


Packet  Header 

16PP194  Channel-Specific  Data  Word 
Intra-Packet  Time  Stamp  (LSLW) 
Intra-Packet  Time  Stamp  (MSLW) 
Intra-Packet  Data  Header  Length  Word 
Data  1 


Intra-Packet  Data  Header  Status  Word 


Isb 

0 


Intra-Packet  Time  Stamp  (LSLW) 

Intra-Packet  Time  Stamp  (MSLW) 

Intra-Packet  Data  Header  Length  Word 

Intra-Packet  Data  Header  Status  Word 

Data  N 

PACKET  TRAILER 


c.  MIL-STD-1553  16PP194  Intra-Packet  Header.  The  IPH  consists  of  the  IPDH  (LENGTH 
and  STATUS)  and  the  IPTS. 

•  MIL-STD-1553  16PP194  Intra-Packet  Data  Header  LENGTH.  The  length  word 
contains  the  length  in  bytes  of  the  intra-packet  data. 


NOTE/^ 

The  intra-packet  length  is  fixed  to  0x18,  24 

r 

bytes. 

•  MIL-STD-1553  16PP194  Intra-Packet  Data  Header  STATUS.  The  status  word 

contains  error  and  special  handling  information  about  the  data.  When  set  to  a  “1”,  the 
error  indicator  bits  reflect  that  such  an  error  is  present  in  the  data  or  occurred  during 
data  reception.  The  format  of  the  status  word  is  shown  in  Ligure  11-23. 
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msb 
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2  0 

TE 

RE 

TM 

RESERVED 

SE 

R 

EE 

RESERVED 

Figure  11-23.  Military  Standard  1553  16PP194  Intra-Packet  Data  Header 

Format 


o  Transaction  Error  (TE).  Bit  15  indicates  an  error  condition  found  in  16PP194 
transaction. 

0  =  No  errors  found  in  current  transaction 
1  =  Error  condition  found  in  transaction 

o  Reset  (RE).  Bit  14  indicates  a  16PP194  bus  master  reset. 

0  =  No  master  reset 
1  =  Master  reset  assertion  detected 

o  Message  Time  Out  (TM).  Bit  13  indicates  a  transaction  time  out  occurred. 

0  =  No  message  time  out 
1  =  Message  time  out 

o  Reserved.  Bits  12-7  are  reserved. 

o  Status  Error  (SE).  Bit  6  indicates  status  word  missing  in  transaction. 

0  =  Status  word  present 
1  =  Status  word  missing 

o  Reserved  (R).  Bits  5-4  are  reserved. 

o  Echo  Error  (EE).  Bit  3  indicates  echo  word  missing  in  transaction. 

0  =  Echo  word  present 
1  =  Missing  echo  word 

o  Reserved.  Bits  2-0  are  reserved. 

•  MIE-STD-1553  16PP194  Intra-Packet  Time  Stamp.  The  IPTS  (64  bits  total)  contains 
a  48-bit  relative  time  stamp  in  the  low-order  bits.  The  16  high-order  bits  are  zero. 

d.  Packet  Eormat.  Unless  an  error  occurred,  as  indicated  by  one  of  the  error  flags  in  the 
IPDH,  the  first  word  following  the  length  should  always  be  the  first  transaction  command 
word.  The  resultant  packets  have  the  format  shown  in  Table  11-18. 

Table  11-18.  MIL-STD-1553  16PP194  Data  Packet 

msb  Isb 

_15 _ 0_ 

Packet  Header _ 

Channel-Specific  Data  (Bits  15-0) 

_ Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  (Bits  0-15) 

_ Intra-Packet  Time  Stamp  (Bits  31-16) _ 
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Intra-Packet  Time  Stamp  (Bits  32-47) 

Intra-Paeket  Time  Stamp  (Bits  48-63) 

Intra-Paeket  Data  Header  Status 

Intra-Packet  Data  Header  Fength 

Command  (I)  (Bits  31-16) 

Command  (I )(Bits  15-0) 

Command  (I)  Eoho(Bits  31-16) 

Command  (I)  Eeho  (Bits  15-0) 

Command  (2)  (Bits  31-16) 

Command  (2)  (Bits  15-0) 

Command  (3)  Go  No-Go  (Bits  31-16) 

Command  (3)  Go  No-Go  (Bits  15-0) 

Command  (4)  Go  No-Go  Eeho  (Bits  31-16) 

Command  (4)  Go  No-Go  Echo  (Bits  15-0) 

Status  (Bits  31-16) 

Status  (Bits  15-0) 

Intra-Packet  Time  Stamp  (Bits  0-15) 

Intra-Paeket  Time  Stamp  (Bits  31-16) 

Intra-Paeket  Time  Stamp  (Bits  32-47) 

Intra-Packet  Time  Stamp  (Bits  48-63) 

Intra-Packet  Data  Header  Status 

Intra-Paeket  Data  Header  Fength 

Command  (I)  (Bits  31-16) 

Command  (I)  (Bits  15-0) 

Command  (I)  Eeho  (Bits  31-16) 

Command  (I)  Eeho  (Bits  15-0) 

Command  (2)  (Bits  31-16) 

Command  (2)  (Bits  15-0) 

Command  (3)  Go  No-Go  (Bits  31-16) 

Command  (3)  Go  No-Go  (Bits  15-0) 

Command  (4)  Go  No-Go  Eeho  (Bits  31-16) 

Command  (4)  Go  No-Go  Eeho  (Bits  15-0) 

Status  (Bits  31-16) 

Status  (Bits  15-0) 

Paeket  Trailer 

e.  MIL-STD-1553  16PP194  Data  Format.  Each  26-bit  16PP194  word  in  a  16PP194 

transaction  shall  be  formatted  into  two  16-bit  words  (Figure  11-24).  The  corresponding 
16PP194  syne  and  parity  bits  will  not  be  formatted  into  the  16PP194  words. 


msb 

15  13 

12  10 
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Isb 

7  0 

BUS  ID 

GAP 

W 

P 

I6PPI94  Data  Word  (bits  24-17) 

16PPI94  Data  Word  (bits  1 6- 1) 

Figure  11-24.  Military  Standard  1553  26-Bit  16PP194  Word 
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MIL-STD-1553  16PP194  Bus  ID  (BUS  ID).  A  three-bit  field  shall  be  used  to 
indicate  bus  identification  as  follows. 


Ill 

Communication  interface 
unit  (CIU)  Left  Bus  A 

no 

CIU  Left  Bus  B 

101 

CIU  Right  Bus  A 

100 

CIU  Right  Bus  B 

on 

Response  Bus  A  and  B 

010 

Response  Bus  A 

001 

Response  Bus  B 

000 

Incomplete  Transaction 

MIL-STD-1553  16PP194  GAP  (GAP).  A  three-bit  field  shall  be  used  to  indicate 
GAP  between  transactions  as  follows. 


111 

GAP  >9.15  ps 

no 

7.55  ps<  GAP  <9.15  ps 

101 

5.95  ps<  GAP  <7.55  ps 

100 

4.35  ps  <  GAP  <  5.95  ps 

on 

2.75  ps<  GAP  <4.35  ps 

010 

2.75  ps<  GAP  <4.35  ps 

001 

1.15  ps  <  GAP  <  2.75  ps 

000 

Not  Applicable 

NOTE^ 

Gap  time  is  measured  from  mid-crossing  of  the 

r 

parity  bit  from  the  previous  received  word  to  mid- 

crossing  of  the  sync  bit  of  the  current  word  in  1-ps 

counts. 

MIL-STD-1553  16PP194  Word  Bit  Error  (W).  If  the  bit  is  set  to  “I,”  this  indicates 
that  a  Manchester  error  was  detected  in  the  word. 

MIL-STD-1553  I6PPI94  Word  Parity  Error  (P).  If  the  bit  is  set  to  “I,”  this  indicates 
that  a  parity  error  occurred  in  the  word. 

16PPI94  Data  Word.  Bits  16-1  contain  the  16PP194  data  field  as  in  Figure  11-25. 
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MSB 


LSB 


16PP194  32-bit  Intra-Packet  Word  Format  (as  it  appears  in  the  data 
packet) 


Figure  1 1-25.  16PP194  Word  Format 


•  16PP194  Data  Word.  Bits  24-17  contain  the  16PP 194  remote  interface  unit  (RIU) 

address  and  RIU  subaddress  as  in  Figure  11-25. 

11.2.5  Analog  Data  Packets 

1 1.2. 5.1  Analog  Data  Packets,  Format  0 

Reserved. 


1 1.2. 5. 2  Analog  Data  Packets,  Format  1 

The  generic  packet  structure  for  analog  data  is  illustrated  in  Table  11-19. 


Table  11-19.  Generic  Analog  Data  Packet,  Format  1 

Packet  Header 

Channel-Specific  Data  Word,  Subchannel  1 

Channel-Specific  Data  Word,  Subchannel  2 

Channel-Specific  Data  Word,  Subchannel  M 

Sample  1 

Sample  2 

Sample  N 

Packet  Trailer 
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An  analog  data  packet  will  contain  a  CSDW  for  each  subchannel  of  analog  data  sampled 
within  that  packet  if  the  SAME  bit  is  set  to  0,  or  it  will  contain  a  single  CSDW  for  the  entire 
analog  packet  if  the  SAME  bit  is  set  to  1 .  This  will  be  followed  by  at  least  one  complete 
sampling  schedule  of  data. 

A  sampling  schedule  is  defined  as  a  sampling  sequence  in  which  each  subchannel, 
described  by  a  CSDW,  is  sampled  at  least  once.  In  many  cases,  due  to  simultaneous  sampling 
rules  and  varied  sampling  rates,  a  particular  subchannel  will  be  sampled  more  than  once  during  a 
sampling  schedule.  In  addition,  multiple  complete  sampling  schedules  may  be  included  in  a 
single  packet.  Eor  these  reasons,  the  number  of  CSDWs  will  usually  be  less  than  the  number  of 
samples. 


Table  11-19  depicts  the  generic  packet  data  structure  for  M  data  subchannels  and  a  single 
sampling  schedule  that  has  a  length  N.  Note  that  the  width  of  the  structure  is  not  related  to  any 
number  of  bits  and  is  merely  intended  to  represent  relative  placement  of  words  within  the  packet. 


NOTE 


The  packet  header  time  in  an  analog  data  packet 
shall  correspond  to  the  first  data  sample  in  the 
packet.  There  are  no  IPHs  in  analog  data  packets. 


a.  Analog  Packet  Channel-Specific  Data.  The  packet  body  portion  of  each  analog  packet 
begins  with  the  CSDW(s).  Each  subchannel  that  is  sampled  with  the  packet  sampling 
schedule  must  have  a  CSDW  within  the  packet.  Only  one  CSDW  is  required  if 
subchannels  are  sampled  at  the  same  sampling  rate  (EACTOR),  and  have  the  same  bits 
per  sample  (EENGTH)  and  same  packing  mode  (MODE).  Bit  28  of  the  CSDW  shall  be 
used  to  indicate  same  sampling  data  rate  for  subchannels. 


The  CSDWs  for  analog  data  packets  are  formatted  as  shown  in  Eigure  11-26. 


msb 

31  29 

28 

27  24 

23  16 

15 

8 

7 

2 

Isb 

1  0 

RESERVED 

SAME 

FACTOR 

TOTCHAN 

SUBCHAN 

EENGTH 

MODE 

Eigure  1 1-26.  Analog  Packet  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-29  are  reserved. 

•  Same.  Bit  28  specifies  if  this  CSDW  applies  for  all  the  channels  included  in  the 
packet  or  if  each  channel  has  its  own  CSDW. 

0  =  Each  analog  channel  has  its  own  CSDW. 

1  =  The  CSDW  is  valid  for  all  analog  channels  stored  in  this  packet. 

•  Factor.  Bits  27-24  are  the  exponent  of  the  power  of  2  sampling  rate  factor 
denominator  for  the  corresponding  subchannel  in  the  range  0  to  15.  (The  sampling 
rate  factor  numerator  is  always  1.) 

0x0  =  Sampling  rate  factor  denominator  2°=  1  =  >  factor  =  1/1 

0x1  =  Sampling  rate  factor  denominator  2^=  2  =  >  factor  =  Ez 

0x2  =  Sampling  rate  factor  denominator  l}=  4  =  >  factor  =  (4 
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OxF  =  Sampling  rate  factor  denominator  2'^=  32768  =  >  factor  =  1/32768 

•  Totchan.  Bits  23-16  indicate  the  total  number  of  analog  subchannels  in  the  packet 
(and  the  number  of  CSDWs  in  the  packet). 

This  field  must  be  the  same  value  in  all  CSDWs  in  a  single  packet.  The  Totchan 
value  may  be  less  than  the  largest  Subchan  value.  This  can  happen  when  a  multi¬ 
channel  analog  input  device  has  some  of  its  subchannels  disabled  (turned  off)  for  a 
specific  acquisition  session.  For  example,  if  an  analog  input  device  has  eight 
subchannels  and  not  all  eight  are  active,  an  analog  data  packet  may  have  three 
subchannels  (Totchan  =  3)  numbered  4,  7,  and  8  (enabled  Subchan  =  4,  7,  8).  The 
number  of  subchannels  (Totchan)  and  the  subchannel  number  for  each  active 
subchannel  (Subchan)  in  a  packet  are  identified  in  the  accompanying  Telemetry 
Attributes  Transfer  Standard  (TMATS)  (Computer- Generated  Data,  Format  1)  packet. 

0x00  =  256  subchannels 
0x01  =  1  subchannel 
0x02  =  2  subchannels 

•  Subchan.  Bits  15-8  indicate  a  binary  value  representing  the  number  or  subchannel  ID 
of  the  analog  subchannel. 

When  an  analog  packet  contains  data  from  more  than  one  subchannel  and  the  CSDWs 
are  not  the  same  for  all  channels  (see  field  Same,  bit  28),  the  CSDWs  must  be 
inserted  into  the  packet  in  ascending  subchannel  number  as  identified  by  this  field. 
The  Subchan  values  in  these  CSDWs  need  not  be  contiguous  (see  Totchan),  but  they 
must  be  in  ascending  decimal  numerical  order  with  the  exception  that  subchannel  0 
(256)  is  last.  If  the  Same  bit  is  set,  the  Subchan  field  shall  be  set  to  zero. 

0x01  =  Subchannel  1 
0x02  =  Subchannel  2 

0x00  =  Subchannel  256 


•  Length.  Bits  7-2  indicate  a  binary  value  representing  the  number  of  bits  in  the 
analog-to-digital  converter. 

000000  =  64-bit  samples 
000001  =  1-bit  samples 

001000  =  8-bit  samples 

001100=  12-bit  samples 


•  Mode.  Bits  1-0  indicate  alignment  and  packing  modes  of  the  analog  data.  When 
Totchan  is  more  than  1,  MODE  must  be  the  same  for  all  subchannels  in  a  single 
packet. 

00  =  Data  is  packed 

01  =  Data  is  unpacked,  Isb  padded 
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10  =  Reserved  for  future  definition 

11  =  Data  is  unpacked,  msb  padded 


NOTE 


For  the  special  case  of  defining  a  single  channel  (Totchan  =  1),  there  are 
two  options:  a)  one  channel  with  no  subchannels;  or  b)  one  channel  as  its 
own  subchannel.  In  such  cases  the  bits  are  to  be  defined  as  follows. 


One  channel  with 
no  subchannel 

One  channel  with 
one  subchannel 

Totchan  (bits  23-16) 

1 

1 

Same  (bit  28) 

1 

0 

Subchan  (bits  15-8) 

0 

1 

b.  Analog  Samples.  A  simultaneous  sampling  scheme  shall  be  employed  to  preserve  timing 
relationships  and  allow  for  accurate  reconstruction  of  the  data.  The  highest  sampling  rate 
required  shall  define  the  primary  simultaneous  sampling  rate  within  the  packet.  The 
primary  simultaneous  sampling  rate  is  identified  in  the  TMATS  file  describing  the 
attributes  of  the  analog  data  packet.  The  rate  at  which  the  other  subchannels  are  sampled 
is  then  defined  by  the  sampling  factor  (1,  Vi,  14,  1/8,  1/16,  1/32768)  for  each  subchannel. 
As  an  example,  a  sampling  factor  of  14  would  yield  that  subchannel  being  sampled  at 
one-fourth  the  primary  simultaneous  sampling  rate  and  a  sampling  factor  of  1  would 
yield  that  subchannel  being  sampled  at  the  primary  simultaneous  sampling  rate. 


Directly  following  the  CSDW(s),  at  least  one  complete  sampling  schedule  shall  be 
inserted  in  the  packet.  The  samples,  within  the  sampling  sequence,  may  be  inserted 
either  unpacked,  msb  packed,  or  Isb  packed  as  described  in  Subsection  11.2.5.2  items 
b(l)  and  b(2).  In  either  case,  one  or  more  subchannels  may  be  included  in  a  single 
packet.  When  multiple  subchannels  are  encapsulated  into  a  single  packet,  the  subchannel 
with  the  highest  sampling  rate  requirement  defines  the  primary  simultaneous  sampling 
rate.  The  rate  at  which  the  other  subchannels  are  sampled  is  defined  by  the  sampling 
factor  (contained  within  the  CSDWs).  Sampling  factors  are  defined  as: 


{  1  3 


v2Ky 


*X 


K  =  0,  1,2,  3,  4,  5,  ... 


of  the  primary  simultaneous  sampling  rate  X. 

The  subchannels  are  then  sampled  and  ordered  such  that: 

•  The  highest  sample  rate  1*X  subchannel(s)  appear  in  every  simultaneous  sample; 


The 


The 


r  1  X 


n 


*  X  subchannel(s)  appear  in  every  2nd  simultaneous  sample; 


—  \  *  X  subchannel(s)  appear  in  every  4th  simultaneous  sample; 

v4j 


. . .  and  so  on  until  all  the  subchannels  are  sampled,  resulting  in  a  complete  sampling 
schedule  of  all  subchannels  described  by  the  CSDWs.  In  doing  so,  the  total  number  of 
simultaneous  samples  (not  the  total  number  of  samples)  will  equal  the  denominator  of  the 
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smallest  sampling  factor  and  all  subchannels  will  be  sampled  in  the  last  simultaneous 
sample. 

For  example,  a  packet  with  six  subchannels  with  sampling  factors  Vi,  1/8,  1,  Vi,  1,  and  1/8 
respectively  will  yield  a  sampling  sequence  within  the  data  packet  as: 


Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 


1:  Subchannels 

1 :  Subchannel  5 

2:  Subchannel  1 

2:  Subchannel  3 

2:  Subchannel  4 

2:  Subchannel  5 

3:  Subchannel  3 

3:  Subchannel  5 

4:  Subchannel  1 

4:  Subchannel  3 

4:  Subchannel  4 

4:  Subchannel  5 

5:  Subchannel  3 

5:  Subchannel  5 

6:  Subchannel  1 

6:  Subchannel  3 

6:  Subchannel  4 

6:  Subchannel  5 

7 :  Subchannel  3 

7 :  Subchannel  5 

8:  Subchannel  1 

8:  Subchannel  2 

8:  Subchannel  3 

8:  Subchannel  4 

8:  Subchannel  5 

8:  Subchannel  6 


Notice  that  the  denominator  of  the  smallest  sampling  factor  defines  the  number  of 
simultaneous  samples  within  the  packet  (in  this  example,  8);  however,  the  total  number 
of  samples  within  the  sampling  schedule  does  not  have  to  equal  the  number  of 
simultaneous  samples  (in  this  example,  26).  Also  notice  that  all  subchannels  are  sampled 
during  the  last  simultaneous  sample.  The  order  of  the  subchannel  samples  in  each 
simultaneous  sample  is  ascending  by  subchannel  number. 

Any  number  of  complete  sampling  schedules  may  be  placed  within  a  packet  so  that  the 
maximum  packet  length  is  not  exceeded. 


(1)  Unpacked  Mode.  In  unpacked  mode,  packing  is  disabled  and  each  sample  is 

padded  with  the  number  of  bits  necessary  to  align  each  word  with  the  next  16-bit 
boundary  in  the  packet.  Four  pad  bits  are  added  to  12-bit  words,  eight  pad  bits  are 
added  to  8 -bit  words,  etc.  All  pad  bits  shall  equal  zero. 
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NOTE^ 

Samples  less  than  8  bits  go  into  a  16-bit 

A 

word  boundary. 

To  illustrate  msb  padding,  given  M  analog  subchannels  mapping  into  N  samples  for 
the  special  case  of  all  samples  having  bit  lengths  of  12  bits,  the  resultant  analog 
packets  with  msb  padding  have  the  form  shown  in  Table  11-20. 


Table  11-20.  Analog  Data  Packet-Unpacked  Mode,  msb  Padding 

msb  Isb 

15 _ 0 

Packet  Header _ 

Channel- Specific  Data  Word,  Subchannel  1  (Bits  15-0) 

Channel- Specific  Data  Word,  Subchannel  1  (Bits  31-16) 

Channel-Specific  Data  Word,  Subchannel  2  (Bits  15-0) 

Channel- Specific  Data  Word,  Subchannel  2  (Bits  31-16) 


Channel- Specific  Data  Word,  Subchannel  M  (Bits  15-0) 


Channel-Specific  Data  Word,  Subchannel  M  (Bits  31-16) 


4  Pad  Bits 

Sample  1,  12  Data  Bits 

4  Pad  Bits 

Sample  2,  12  Data  Bits 

4  Pad  Bits 

Sample  3,  12  Data  Bits 

4  Pad  Bits 

Sample  N,  12  Data  Bits 

Packet  Trailer 

To  illustrate  Isb  packing,  given  M  analog  subchannels  mapping  into  N  samples  for 
the  special  case  of  all  samples  having  bit  lengths  of  12  bits,  the  resultant  analog 
packets  with  Isb  padding  have  the  form  shown  in  Table  11-21. 

Table  11-21.  Analog  Data  Packet-Unpacked  Mode,  Isb  Padding 

msb 

15 _ 

Packet  Header 

Channel-Specific  Data  Word,  Subchannel  1  (Bits  15-0) 

Channel-Specific  Data  Word,  Subchannel  1  (Bits  31-16) 

Channel-Specific  Data  Word,  Subchannel  2  (Bits  15-0) 

Channel-Specific  Data  Word,  Subchannel  2  (Bits  31-16) 


Channel-Specific  Data  Word,  Subchannel  M  (Bits  15-0) 


Isb 

0 
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Channel-Specific  Data  Word,  Subchannel  M  (Bits  31-16) 

Sample  1,  12  Data  Bits 

4  Pad  Bits 

Sample  2,  12  Data  Bits 

4  Pad  Bits 

Sample  3,  12  Data  Bits 

4  Pad  Bits 

Sample  N,  12  Data  Bits 

4  Pad  Bits 

Packet  Trailer 

(2)  Packed  Mode.  In  packed  mode,  packing  is  enabled  and  padding  is  not  added  to 
each  data  word;  however,  if  the  number  of  bits  in  the  packet  are  not  an  integer 
multiple  of  16,  then  Y  filler  bits  will  be  used  to  msb  fill  the  last  data  word,  forcing 
alignment  on  a  16-bit  boundary.  The  value  of  Y  is  16  minus  the  integer  remainder 
of  L,  the  total  number  of  data  bits  in  the  packet,  divided  by  16  and  is 
mathematically  expressed  as: 

Y=  16-(MODULUS{L,16}). 

To  illustrate  msb  padding,  given  M  analog  subchannels  mapping  into  N  samples  for 
the  special  case  of  all  samples  having  bit  lengths  of  12  bits,  the  resultant  analog 
packets  with  padding  bits  at  the  end  of  the  Nth  sample  have  the  form  shown  in 
Table  11-22. 


Table  11-22.  Analog  Data  Packet-Packed  Mode  Packet 

msb 

15 

Isb 

0 

Packet  Header 

Channel- Specific  Data  Word,  Subchannel  1  (Bits  15-0) 

Channel- Specific  Data  Word,  Subchannel  1  (Bits  31-16) 

Channel-Specific  Data  Word,  Subchannel  2  (Bits  15-0) 

Channel- Specific  Data  Word,  Subchannel  2  (Bits  31-16) 

Channel- Specific  Data  Word,  Subchannel  M  (Bits  15-0) 

Channel-Specific  Data  Word,  Subchannel  M  (Bits  31-16) 

Sample  2  (Bits  3-0) 

Sample  1  (Bits  11-0) 

Sample  3  (Bits  7-0) 

Sample  2  (Bits  11-4) 

Y  Padding  Bits 

Sample  N  (Bits  11-0) 

Packet  Trailer 
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11.2.6  Discrete  Data  Packets 

11.2.6.1  Discrete  Data  Packets,  Format  0. 

Reserved. 

1 1.2. 6. 2  Discrete  Data  Packets,  Format  1 

A  packet  with  discrete  data  has  the  basic  structure  shown  in  Table  1 1-23.  Note  that  the 
width  of  the  structure  is  not  related  to  any  number  of  bits.  This  drawing  is  merely  intended  to 
represent  relative  placement  of  data  in  the  packet.  One  to  32  discrete  states  may  be  recorded  for 
each  event. 

Table  11-23.  General  Discrete  Data  Packet,  Format  1 

Packet  Header _ 

Channel-Specific  Data 
Intra-Packet  Header  for  Event  1 
Event  1  States 

Intra-Packet  Header  for  Event  2 
Event  2  States 


Intra-Packet  Header  for  Event  N 
Event  N  States 
Packet  Trailer 


a.  Discrete  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  discrete 
packet  begins  with  the  CSDW,  which  is  formatted  as  shown  in  Eigure  11-27. 


msb 

31 

8 

7 

3 

2 

Isb 

0 

RESERVED 

EENGTH 

MODE 

Eigure  1 1-27.  Discrete  Packet  Channel  Data  Word 


•  Reserved.  Bits  31-8  are  reserved. 

•  Eength.  Bits  7-3  indicate  a  binary  value  representing  the  number  of  bits  in  the  event. 
The  value  of  zero  indicates  32  bits. 

•  Mode.  Bits  2-0  indicate  the  mode  of  accessing  the  discrete  data. 

o  Bit  0:  indicates  the  record  state. 

0  =  discrete  data  is  recorded  when  the  state  changes 
1  =  discrete  data  is  recorded  on  a  time  interval  basis 

o  Bit  1 :  indicates  the  alignment  of  the  data. 

0  =  lsb 
1  =  msb 

o  Bit  2:  reserved. 
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b.  Discrete  Data.  After  the  channel- specific  data,  discrete  data  (Figure  11-28)  is  inserted  in 
the  packet.  Discrete  data  are  described  as  events.  Each  event  includes  the  event  state  for 
each  discrete  input  and  the  corresponding  intra-packet  time.  The  event  state  is  a  32-bit 
word  that  provides  the  logical  state  of  each  discrete  input. 


msb 

31 

30 

1 

Isb 

0 

D31 

D30  ... 

Dl 

DO 

Figure  1 1-28.  Discrete  Data  Format 


•  Discrete  Event  Bits.  Bits  31-0  indicate  the  states  of  the  discrete  event  bits. 

Bit  31:  indicates  discrete  31  (D31)  state. 

0  =  discrete  3 1  is  at  state  0 
1  =  discrete  3 1  is  at  state  1 

Bit  30:  indicates  discrete  30  (D30)  state. 

0  =  discrete  30  is  at  state  0 
1  =  discrete  30  is  at  state  1 

Bit  1:  indicates  discrete  1  (Dl)  state. 

0  =  discrete  1  is  at  state  0 
1  =  discrete  1  is  at  state  1 

Bit  0:  indicates  discrete  0  (DO)  state. 

0  =  discrete  0  is  at  state  0 
1  =  discrete  0  is  at  state  1 

c.  Discrete  Event  Intra-Packet  Header.  All  discrete  events  shall  include  an  IPH  consisting 
of  an  IPTS  only,  which  is  inserted  immediately  before  the  discrete  event.  The  length  of 
the  IPH  is  fixed  at  8  bytes  (64  bits)  positioned  contiguously,  arranged  in  the  sequence 
shown  in  Figure  11-29. 

msb 

^1 _ 

Time  (ESEW) 

Time  (MSEW) 

Figure  1 1-29.  Discrete  Event  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  discrete  event. 
First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following 
values: 

(1)  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  of  the  discrete  event  with  bits 
31  to  16  in  the  second  long  word  zero  filled;  or 

(2)  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item 
g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags  (Subsection 
11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data  bit  of  the  discrete 
event.  The  discrete  data  packet  format  is  presented  in  Table  11-24. 


Isb 

0 
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Table  11-24.  Discrete  Data  Packet  Format 

msb  Isb 

15  0 

Packet  Header 

Channel- Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Event  1  (Bits  15-0) 

Intra-Packet  Time  Stamp  for  Event  1  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Event  1  (Bits  47-32) 

Intra-Packet  Time  Stamp  for  Event  1  (Bits  63-48) 

States  for  Event  1  (Bits  15-0) 

States  for  Event  1  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Event  N  (Bits  15-0) 

Intra-Packet  Time  Stamp  for  Event  N  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Event  N  (Bits  47-32) 

Intra-Packet  Time  Stamp  for  Event  N  (Bits  63-48) 

States  for  Event  N  (Bits  15-0) 

States  for  Event  N  (Bits  31-16) 

Packet  Trailer 

11.2.7  Computer-Generated  Data  Packets 

Packets  with  computer-generated  data  have  the  basic  structure  shown  in  Table  11-25. 
Formats  0,  1,2,  and  3  are  used  to  add  information  packets  to  recorded  data.  This  information 
contains  annotation  data,  setup  records,  events,  or  index  information  for  the  data  that  has  been 
recorded.  The  width  of  the  structure  is  not  related  to  any  number  of  bits.  This  drawing  is  merely 
intended  to  represent  relative  placement  of  data  in  the  packet. 


NOTE 


y 


Computer-generated  data  is  defined  as  non-external  data  or  data  generated 
within  the  recorder.  After  the  CSDW,  the  computer-generated  data  is 
inserted  in  the  packet.  The  organization  and  content  of  the  computer¬ 
generated  data  is  determined  by  the  specific  format  type. 


Table  11-25.  General  Computer-Generated  Data  Packet  Format 

Packet  Header _ 

Channel-Specific  Data _ 

Computer  Generated  Data 
Packet  Trailer 


1 1 .2.7.1  Computer-Generated  Data  Packets  Format  0,  User-Defined 

Format  0  enables  the  insertion  of  user-defined  computer-generated  data.  Data  shall  not 
be  placed  in  packets  of  this  type  if  the  data  type  is  already  defined  within  this  standard  nor  shall 
data  be  inserted  in  this  packet  if  it  is  directly  generated  from  an  external  input  to  the  recorder. 
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•  Format  0  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  Format  0 
packet  begins  with  the  CSDW,  which  is  formatted  as  shown  in  Figure  11-30. 

•  Reserved.  Bits  31-0  are  reserved, 
msb 

_ 

RESERVED 

Figure  1 1-30.  Computer-Generated  Format  0  Channel- Specific  Data  Word 


Isb 

0 


NOTE 


y 


For  this  format,  bits  31-0  are  declared  reserved; 
however,  they  are  considered  as  “User”  or 
“Application”  defined. 


1 1.2. 7. 2  Computer-Generated  Data  Packets  Format  1,  Setup  Records 

Format  1  defines  a  setup  record  that  describes  the  hardware,  software,  and  data  channel 
configuration  used  to  produce  the  other  data  packets  in  the  file.  The  organization  and  content  of 
a  Format  1  setup  record  is  indicated  in  the  CSDW  FRMT  field. 

A  single  setup  record  may  span  multiple  consecutive  packets.  When  spanning  multiple 
packets,  the  sequence  counter  shall  increment  in  the  order  of  segmentation  of  the  setup  record, 
n+X. 

a.  Format  1  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  Format  1  packet 
begins  with  the  CSDW,  which  is  formatted  as  shown  in  Figure  11-31. 


msb 

31 

10 

9 

8 

7 

Isb 

0 

RESERVED 

ERMT 

SRCC 

RCCVER 

Figure  11-31.  Computer-Generated  Format  1  Channel- Specific  Data  Word 


•  Reserved.  Bits  31-10  are  reserved. 


•  FRMT.  Bit  9  is  the  setup  record  format. 


0  =  Setup  record  lAW  Chapter  9  ASCII  Format 
1  =  Setup  record  lAW  Chapter  9  XML  Format 


NOTE 


y 


It  is  not  permissible  to  have  both  ASCII  and  XML 
Chapter  9  TMATS  attributes  in  the  same  session 
(e.g.,  recording). 


•  Setup  Record  Configuration  Change  (SRCC).  Bit  8  indicates  if  the  recorder 
configuration  contained  in  the  previous  setup  record  packet(s)  of  the  current 
recording  session  (defined  as  .RECORD  to  .STOP)  has  changed. 

0  =  Setup  record  configuration  has  not  changed 
1  =  Setup  record  configuration  has  changed 
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NOTE 


When  a  setup  record  configuration  change  has  taken  place,  bit  8  (SRCC) 
shall  be  set  to  1  and  the  new  setup  record  packet  will  be  committed  to  the 
stream  prior  to  any  new  or  changed  data  packets  being  committed  to  the 
stream.  The  next  setup  record  packet(s)  committed  to  the  stream,  if  not 
changed  from  this  new  setup  record,  shall  clear  the  SRCC  bit  to  0. 


NOT^^ 

Prior  to  the  new  setup  record  being  committed  to  the 
stream,  a  setup  record  configuration  change  event 
packet  shall  be  inserted  into  the  stream. 

NOT^^ 

Each  new  setup  record  packet  must  adhere  to  all 
applicable  setup  record  requirements  including,  but  not 
limited  to,  the  minimum  required  TMATS  attributes. 

•  RCC  106  Version  (RCCVER).  Bits  7-0  specify  which  RCC  release  version  applies 
and  to  which  the  following  recorded  data  complies  with.  The  value  shall  be 
represented  by  the  following  bit  patterns. 

0x00  through  0x06  =  Reserved 

0x07  =  RCC  106-07 

0x08  =  RCC  106-09 

0x09  =  RCC  106-11 

0x0A  =  RCC  106-13 

0x0B  =  RCC  106-15 

0x0C  =  RCC  106-17 

OxOD  through  OxFF  =  Reserved 

Individual  Chapter  1 1  data  types  and  their  format/content  compliance  and 
applicability  with  the  RCC  release  version  are  defined  in  Subsection  1 1.2. 1.1  item  e. 

Note  that  this  field  was  known  as  “CHIOVER”  in  RCC  versions  106-04  through  106- 
15,  where  it  was  described  in  Chapter  10  Subsection  10.6.7.2. 

1 1.2. 7. 3  Computer-Generated  Data  Packets  Format  2,  Recording  Event 

Eormat  2  defines  a  “Recording  Event”  packet  that  contains  the  occurrence  and 
information  of  one  or  more  individual  events  that  have  been  defined  within  the  Eormat  1  setup 
record  lAW  “Recording  Events”  attribute.  If  the  recording  events  information  is  larger  than  the 
maximum  packet  size  of  512  KB,  the  recording  events  information  may  be  contained  in  multiple 
packets  using  the  major  packet  header  sequence  number. 

Events  associated  with  the  .EVENT  command  defined  in  Chapter  6  Subsection  6.2.4.13 
can  only  be  directly  accessed  from  the  acquisition  system  itself  (e.g.,  recorder  system)  and  are 
not  contained  within  the  output  or  recorded  data.  This  does  not  preclude  defining  an  event 
driven  by  the  .EVENT  command  to  also  be  defined  within  the  recording  event  setup  record 
information  and  placed  in  the  appropriate  event  entry  within  an  event  packet.  The  .EVENT 
command  and  the  “Recording  Event”  packets  will  not  be  directly  linked  in  this  standard  and  any 
linking  between  the  two  will  be  an  implementation  of  this  standard  within  a  recorder. 


11-45 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


NOTE  ^ 

It  is  not  the  intent  for  the  event  packets  within  the 

r 

data  to  be  directly  coupled  with  recorder  events  per 

the  .EVENT  command  in  Chapter  6  Subsection 

6.2.4.13. 

a.  Event  Packet  Location.  Recording  event  packets  may  be  placed  at  any  location  within 
the  recording  after  the  first  time  data  packet  and  before  the  last  root  index  packet.  This 
may  be  at  the  time  each  event  occurs,  after  multiple  events  have  occurred,  or  at  an 
interval  of  time  or  packets.  The  complete  event  log  of  a  recording  (defined  in  Subsection 
1 1.2. 7. 3  item  c)  is  constituted  by  the  contents  of  all  event  packets  in  a  recording 
concatenated  in  order  of  which  the  event(s)  occurred  in  time. 


NOTE^ 

Index  packets  will  be  enabled  if  recording  event 

packets  are  enabled.  Note  that  Index  packets  are  only 

r 

meaningful  if  a  Chapter  10  file  is  being  used  to  record 

packets. 

b.  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  Format  2  packet  begins 
with  the  CSDW,  which  is  formatted  as  shown  in  Figure  11-32. 


msb 

Isb 

31 

30 

12 

11 

0 

IPDH 

RESERVED 

REEC 

Figure  1 1-32.  Computer-Generated  Format  2  Channel- Specific  Data  Word 


•  Recording  Event  Intra-Packet  Data  Header.  Bit  3 1  indicates  the  presence  of  the 
IPDH. 

0  =  Recording  event  IPDH  not  present 
1  =  Recording  event  IPDH  present 

•  Reserved.  Bits  30-12  are  reserved. 

•  Recording  Event  Entry  Count  (REEC).  Bits  1 1-0  are  an  unsigned  binary  that 
identifies  the  count  of  recording  event  entries  included  in  the  packet. 


c.  Event  Period  of  Capture.  The  event  period  of  capture  (Figure  11-33)  is  defined  to 
encompass  the  events  occurring  from  the  time  a  .RECORD  command  (Chapter  6, 
Subsection  6.2.2.31)  is  issued  (if  it  is  the  first  recording)  until  the  time  a  .STOP  command 
(Chapter  6,  Subsection  6. 2. 3. 9)  is  issued.  If  there  is  a  previous  recording,  the  period  of 
capture  is  described  as  encompassing  those  events  that  occur  from  the  previous 
recording’s  .STOP  command  until  the  .STOP  command  of  the  current  recording.  This 
ensures  that  any  events  that  occurred  between  recordings  will  be  captured  and  will 
include  special  indicators  that  the  event  occurred  between  .STOP  and  .RECORD 
commands. 
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Priority  conditions  and  event  limit  counts  are  defined  in  the  setup  record  attributes  for 
each  defined  event.  The  ability  to  put  finite  limits  on  events  during  periods  of  capture 
precludes  overflowing  buffers  or  media  capacities.  These  priority  conditions  and  event 
limit  counts  are  as  follows. 


Priority  1 

The  defined  event  will  always  be  captured  during  and  in  between 
recordings. 

Priority  2 

The  defined  event  will  always  be  captured  during  recordings  and  up  to 
a  limit  count  between  recordings. 

Priority  3 

The  defined  event  will  always  be  captured  during  recordings  and  not 
captured  between  recordings. 

Priority  4 

The  defined  event  will  be  captured  up  to  a  limit  count  during 
recordings  and  between  recordings. 

Priority  5 

The  defined  event  will  be  captured  up  to  a  limit  count  for  each  defined 
event  during  recordings  and  not  captured  between  recordings. 

Event  Condition  of  Capture.  Event  trigger  mode  conditions  during  the  event  period  of 
capture  are  defined  in  the  setup  record  attributes  for  each  defined  event.  These 
MEASUREMENT  DISCRETE,  MEASUREMENT  EIMIT,  or  MEASUREMENT 
CHANGE  trigger  mode  conditions  are  as  follows. 

Mode  1: 

Capture  MEASUREMENT  DISCRETE  event  at  each  On  (I)  and  Off 
(0)  mode  transition  sampling. 

Mode  2: 

Capture  MEASUREMENT  DISCRETE  event  at  each  On  (I)  mode 
transition  sampling. 

Mode  3: 

Capture  MEASUREMENT  DISCRETE  event  at  each  Off  (0)  mode 
transition  sampling. 

Mode  4: 

Capture  MEASUREMENT  EIMIT  event  at  each  high  and  low  value 
transition  sampling. 

Mode  5: 

Capture  MEASUREMENT  EIMIT  event  at  each  high  value  transition 
sampling. 
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Mode  6:  Capture  MEASUREMENT  EIMIT  event  at  each  low  value  transition 
sampling. 


Mode  7:  Capture  MEASUREMENT  CHANGE  event  on  each  change  of  value 
from  the  previous  value. 


NOTE 


If  Event  Type  is  MEASUREMENT  DISCRETE,  MEASUREMENT  EIMIT, 
or  MEASUREMENT  CHANGE,  the  trigger  measurement  must  be  fully 
described  using  the  setup  record  attributes  for  PCM,  bus,  analog,  or  discrete 
channels.  The  trigger  measurement  source  and  measurement  name  shall  be 
identified  in  the  event  definition. 


e.  Event  Initial  Capture.  Event  initial  capture  conditions  are  defined  in  the  setup  record 
attributes  for  each  defined  event.  This  determines  if  an  event  will  be  captured  initially 
prior  to  the  transition  mode  set  for  the  event  if  the  transition  has  already  occurred  prior  to 
the  event  period  of  capture. 

Eor  a  Mode  7  capture  of  a  MEASUREMENT  CHANGE  event,  there  shall  be  an  option 
for  an  initial  value  in  the  setup  record  that  does  not  generate  an  event  but  each  successive 
value  change  from  this  initial  value  shall  generate  an  event.  Event  limit  counts  for  mode 
7  shall  be  valid  on  the  number  of  events  generated  based  on  successive  value  changes 
from  each  previous  value. 

f.  Event  Trigger  Measurement  Description.  If  Event  Type  is  MEASUREMENT 
DISCRETE,  MEASUREMENT  EIMIT,  or  MEASUREMENT  CHANGE,  the  event 
trigger  measurement  must  be  fully  described  using  the  setup  record  attributes  for  PCM, 
bus,  analog,  or  discrete  channels.  This  shall  include  at  a  minimum  the  following 
attributes  for  the  trigger  measurement. 

(1)  Measurement  source  (via  data  link  name) 

(2)  Measurement  name 

(3)  Applicable  measurement  value  definition  or  bit  mask 

(4)  High  measurement  value  (if  MEASUREMENT  EIMIT  at  or  above  the  high  limit  is 
used  to  trigger  the  event) 

(5)  Eow  measurement  value  (if  MEASUREMENT  EIMIT  at  or  below  the  low  limit  is 
used  to  trigger  the  event) 

(6)  (Optional)  Initial  measurement  value  (if  MEASUREMENT  CHANGE  is  used  to 
trigger  the  event) 

(7)  Applicable  measurement  name  engineering  unit  conversion 

g.  Recording  Event  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the 
recording  event  entry  as  follows. 

(1)  The  48-bit  RTC  that  corresponds  to  the  event  entry  with  bits  31  to  16  in  the  second 
long  word  zero-filled.  Eor  event  types  that  are  MEASUREMENT  DISCRETE  or 
MEASUREMENT  EIMIT,  the  time  tag  will  correspond  to  the  data  packet  timing 
mechanism  containing  the  trigger  measurement.  This  will  either  be  the  packet 
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header  RTC  value  or,  if  enabled,  the  IPTS  -  whichever  most  accurately  provides  the 
time  the  event  occurred;  or 

(2)  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item 
g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags  (Subsection 
11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  event  entry.  For  event 
types  that  are  MEASUREMENT  DISCRETE  or  MEASUREMENT  EIMIT,  the 
time  tag  will  correspond  to  the  data  packet  timing  mechanism  containing  the  trigger 
measurement.  This  will  either  be  the  packet  secondary  header  or,  if  enabled  and 
using  an  absolute  time  value,  the  IPTS  -  whichever  most  accurately  provides  the 
time  the  event  occurred. 

h.  (Optional)  Recording  Event  Intra-Packet  Data  Header.  These  8  bytes  contain  the 
absolute  time  of  the  event  occurrence.  The  time  source  and  format  shall  be  derived  from 
the  Time  Data  Packet,  Eormat  1.  Unused  high-order  bits  will  be  zero-filled  as  needed, 
depending  on  the  time  type  of  the  time  data  packet.  The  format  of  the  recording  event 
IPH  is  presented  in  Eigure  11-34. 

msb 

^1 _ 

Intra-Packet  Time  Stamp  (ESEW) 

Intra-Packet  Time  Stamp  (MSEW) 

_ (Optional)  Intra-Packet  Data  Header  (ESEW) _ 

(Optional)  Intra-Packet  Data  Header  (MSEW) 

Eigure  1 1-34.  Recording  Event  Intra-Packet  Header 

i.  Event  Packet  Entry  Eormat.  Table  11-26  and  Eigure  11-35  present  the  general  recording 
event  packet  format  and  recording  event  entry  layout. 


Table  11-26.  General  Recording  Event  Packet  Format 

Packet  Header 

(Optional)  Packet  Secondary  Header 

Channel-Specific  Data 

Intra-Packet  Time  Stamp  for  Event  I 

(Optional)  Intra-Packet  Data  Header  for  Event  I 

Recording  Event  I 

Intra-Packet  Time  Stamp  for  Event  2 

(Optional)  Intra-Packet  Data  Header  for  Event  2 

Recording  Event  2 

Intra-Packet  Time  Stamp  for  Event  N 

(Optional)  Intra-Packet  Data  Header  for  Event  N 

Recording  Event  N 

Packet  Trailer 

Isb 

0 
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msb 

31  29 

28 

27 

12 

11 

Isb 

0 

RESERVED 

EO 

EVENT  COUNT 

NUMBER 

Figure  1 1-35.  Recording  Event  Entry  Eayout 


•  Reserved.  Bits  31-29  are  reserved  for  future  growth  and  shall  be  zero-filled. 

•  Event  Occurrence  (EO).  Bit  28  indicates  Event  Occurrence  State. 

0  =  Indicates  the  event  occurred  after  the  .STOP  command  and  before  the 
.RECORD  command. 

1=  Indicates  the  event  occurred  after  the  .RECORD  command  and  before  the 
.STOP  command. 

•  Event  Count.  Bits  27-12  represent  an  unsigned  binary  that  identifies  the  count  of  up 
to  65,535  occurrences  of  an  individually  defined  event  (as  defined  by  Event  Number 
in  the  following  paragraph).  Event  occurrence  counts  shall  begin  at  0x0  for  the  first 
occurrence  of  an  individual  event  type  (identified  by  the  event  number).  The  event 
count  can  roll  over  to  0x0  and  begin  to  count  up  again.  The  event  count  applicability 
is  for  each  event  period  of  capture  as  defined  in  Subsection  1 1.2.7. 3  item  c.  The 
event  count  shall  start  from  0x0  at  the  beginning  of  each  event  period  of  capture 
incrementing  at  n-i-Oxl  to  OxEEFE  for  each  event  occurrence.  If  the  event  count 
reaches  OxEEFF  within  the  event  period  of  capture  it  shall  roll  over  to  0x0. 

•  Event  Number.  Bits  11-0  represent  an  unsigned  binary  that  identifies  4096  individual 
events  types  defined  in  the  corresponding  setup  record  recording  event  number.  The 
event  number  shall  begin  at  0x0  for  the  first  event  type  defined  in  the  setup  record 
and  increment  n+\  for  the  next  event  type  defined  in  the  setup  record. 


11.2.7.4 


Computer-Generated  Data  Packets  Eormat  3,  Recording  Index 


NOTE 


The  Recording  Index  mechanism  is  only  meaningful  in 
the  context  of  a  Chapter  10  system,  and  is  undefined 
where  Chapter  1 1  packets  are  being  streamed. 


This  defines  an  index  packet  for  an  individual  recording  file  used  for  direct  access  into 
the  recording  file.  Recording  index  packets  will  be  enabled  when  recording  event  packets  are 
enabled.  There  are  two  types  of  index  packets. 


Root  Index  Packets.  These  packets  contain  zero-based  byte  offset  entries  that  are  the 
beginning  of  node  index  packets.  The  last  entry  will  be  an  offset  to  the  beginning  of 
the  previous  root  index  packet  in  its  chain  if  there  is  more  than  one  root  index  packet, 
or  to  the  beginning  of  the  root  index  packet  itself,  if  this  root  index  packet  is  either  the 
first  root  index  packet  of  the  recording  or  the  only  root  index  packet. 


NOTE 


Root  index  packets  shall  not  contain  filler  in  the 
packet  trailer  and  shall  contain  a  32-bit  data 
checksum  in  the  packet  trailer. 
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NOTE^ 

Each  recording  file  with  indexes 

r 

enabled  shall  have  at  a  minimum 

one  root  index  type  packet. 

•  Node  Index  Packets.  These  packets  contain  node  item  structures  containing 
information  about  the  location  of  data  packets  throughout  the  recording. 


NOTE 


At  a  minimum,  an  index  entry  shall  exist  for  each  time  data 
packet  in  the  recording  and,  at  a  minimum,  an  index  entry 
shall  exist  for  each  recording  event  packet  in  the  recording. 


NOTE 


If  the  recording  index  type  uses  a  count  rather  than  time,  the  time  data  packets 
and  computer-generated  data  packets  are  not  included  in  the  count  interval. 

-If  the  recording  index  type  uses  a  time  rather  than  count,  the  time  data 
packets  are  not  included  in  the  time  interval.  If  the  time  count  value  coincides 
with  the  time  packet  rate,  then  one  index  entry  shall  be  created. 


NOTE 


If  the  recording  indexes  are  enabled  the  Computer- 
Generated  Data  Packet,  Format  1  setup  record  count 
or  time  interval  value  cannot  be  zero. 


a. 


Recording  Index  Packet  Location.  If  indexes  are  enabled,  a  root  index  packet  (Figure 
11-36)  will  be  the  last  packet  in  any  recording  file.  More  than  one  root  index  type  packet 
may  be  created  and  may  be  located  within  the  recording.  Root  index  packets  are  not 
required  to  be  contiguous.  Node  index  types  may  be  placed  at  any  location  within  the 
recording  after  the  first  time  data  packet  and  before  the  last  root  index  packet.  This  may 
be  at  an  interval  of  time  or  packets.  If  indexes  are  based  on  a  time  interval,  the  time 
interval  shall  be  referenced  to  and  based  on  10  MHz  RTC  counts.  When  a  time-based 
index  time  interval  expiration  takes  place  and  all  packet(s)  are  open  (not  generated),  the 
index  offset  and  time  stamp  will  be  based  on  the  first  of  the  opened  packets  generated. 
Packet  generation  and  packet  generation  time  shall  apply  per  the  definitions  in  Subsection 


11.2.1. 
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Channel  ID 


Data  Type 


V 


Data  Packet  Offset 

S . 


Packet  Header 
•CSDW 


File  Size  (Opt)  \ 

IPH  \ 


Node  Entry  1 

-  IPH 


iPH 
Node  Entry  n 


v 


“Intra-Packet  Header”  (IPH) 
contains  a  Intra-Packet  Time 
Stamp  &  optional  Intra-Packet 
Data  Header 


“Root  Offset”  points  to  the 
previous  Root  Index  Packet  or 
to  itself  if  it  is  the  only  or  first 
Root  Index  Packet 


Setup  Record  Packet 


Time  Data  Packet 


Beginning  of  Recording  Session 


Data  Packet 


Node  index  Packet  1 


Data  Packet 


Time  Data  Packet 


Data  Packet 


Event  Packet 


Time  Data  Packet 


Data  Packet 


Data  Packet 


Root  index  Packet  1 


Time  Data  Packet 


Node  index  Packet  n 


Root  index  Packet  n 


V 


Packet  Header 


End  of  Recording  Session 


A 

N 


V 


\ 

CSDW  S 

File  Size  (Opt)  \ 


iPH 


Node  Offset  1 


iPH 


iPH 

Node  Offset  n 


iPH 

Root  Offset  V 

Packet  Traiier  S 


V 


Figure  11-36.  Format  Showing  Root  Index  Packet 


b.  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  Format  3  packet  begins 
with  the  CSDW,  which  is  formatted  as  shown  in  Figure  11-37. 


msb 

31 

30 

29 

28 

16 

15 

Isb 

0 

IT 

FSP 

IPDH 

RESERVED 

INDEX  ENTRY  COUNT 

Figure  1 1-37.  Computer-Generated  Format  3  Channel- Specific  Data  Word 


•  Index  Type  (IT).  Bit  3 1  indicates  the  type  of  index  packet. 

0  =  Root  index 
1  =  Node  index 

•  File  Size  Present  (FSP).  Bit  30  indicates  if  the  file  size  at  the  time  the  index  packet 
was  created  is  present. 

0  =  File  size  not  present 
1  =  File  size  present 

•  Index  Intra-Packet  Data  Header.  Bit  29  indicates  the  presence  of  the  IPDH. 

0  =  Index  IPDH  not  present 
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1  =  Index  IPDH  present 


•  Reserved.  Bits  28-16  are  reserved. 


Index  Entry  Count.  Bits  15-0  indicate  the  unsigned  binary  value  of  the  number  of 
index  entries  included  in  the  packet.  An  integral  number  of  complete  index  entries 
will  be  in  each  packet. 


NOTE 


The  IPDH  presence  once  set  by  bit  29 
shall  be  the  same  state  for  the  entire 
recording. 


c.  Recording  Index  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the 
recording  index  entry  as  follows. 

•  The  48-bit  RTC  that  corresponds  to  the  index  entry,  with  bits  31  to  16  in  the  second 
long  word  zero-filled.  For  node  index  packets  this  corresponds  to  the  first  bit  in  the 
packet  body  of  the  packet  associated  with  the  node  index  item;  or 

•  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item  g). 
The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  tag  shall  be  correlated  to  the  index  entry.  For  node  index  packets 
this  corresponds  to  the  first  bit  in  the  packet  body  of  the  packet  associated  with  the 
node  index  item. 

d.  (Optional)  Recording  Index  Intra-Packet  Data  Header.  These  8  bytes  contain  the  absolute 
time  of  the  index  entry.  The  time  source  and  format  shall  be  derived  from  the  Time  Data 
Packet,  Format  1 .  Unused  high-order  bits  will  be  zero-filled  as  needed,  depending  on  the 
time  type  of  the  time  data  packet.  Figure  11-38  presents  the  format  of  the  recording 
index  IPH. 

msb 

^1 _ 

Intra-Packet  Time  Stamp  (LSLW) 

Intra-Packet  Time  Stamp  (MSLW) 

(Optional)  Intra-Packet  Data  Header  (LSLW) 

(Optional)  Intra-Packet  Data  Header  (MSLW) 

Figure  11-38.  Recording  Index  Intra-Packet  Header 

e.  Root  Index  Packet  Entry  Format.  A  root  index  packet  contains  a  node  index  offset  entry 
or  entries  using  the  format  shown  in  Table  11-27  and  Table  11-28. 

Table  11-27.  General  Recording  Root  Index  Packet 

Packet  Header _ 

(Optional)  Packet  Secondary  Header _ 

Channel-Specific  Data 
(Optional)  Root  Index  File  Size 
Intra-Packet  Time  Stamp  for  Node  Index  1 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  1 _ 


Isb 

0 
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Node  Index  Offset  1 


Intra-Packet  Time  Stamp  for  Node  Index  N 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  N 

Node  Index  Offset  N 

Intra-Packet  Time  Stamp  for  Root  Index 

(Optional)  Intra-Packet  Data  Header  for  Root  Index 

Root  Index  Offset 

Packet  Trailer 


Table  11-28.  Recording  Root  Index  Entry  Layout 

msb  Isb 

31  0 

(Optional)  File  Size  (LSLW) 

(Optional)  File  Size  (MSLW) 

Intra-Packet  Time  Stamp  for  Node  Index  1  (LSLW) 

Intra-Packet  Time  Stamp  for  Node  Index  1  (MSLW) 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  1  (LSLW) 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  1  (MSLW) 

Node  Index  Offset  1  (LSLW) 

Node  Index  Offset  1  (MSLW) 

Intra-Packet  Time  Stamp  for  Node  Index  N  (LSLW) 

Intra-Packet  Time  Stamp  for  Node  Index  N  (MSLW) 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  N  (LSLW) 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  N  (MSLW) 

Node  Index  Offset  N  (LSLW) 

Node  Index  Offset  N  (MSLW) 

Intra-Packet  Time  Stamp  for  Root  Index  (LSLW) 

Intra-Packet  Time  Stamp  for  Root  Index  (MSLW) 

(Optional)  Intra-Packet  Data  Header  for  Root  Index  (LSLW) 

(Optional)  Intra-Packet  Data  Header  for  Root  Index  (MSLW) 

Root  Index  Offset  (LSLW) 

Root  Index  Offset  (MSLW) 

•  (Optional)  Root  Index  File  Size.  These  8  bytes  are  an  unsigned  binary  that  identifies 
the  current  size  in  bytes  of  the  file  at  the  time  the  root  index  packet  was  created  and 
placed  into  the  recording.  This  value  should  be  the  same  as  the  root  index  offset. 

The  file  size  is  required  when  a  recording  is  split  across  multiple  media,  individual  or 
multiple  channels  are  split  from  the  original  recording  file,  or  time  slices  are  extracted 
from  the  original  recording.  In  all  cases  the  original  recording  file  size  will  allow 
recalculation  and/or  replacement  of  the  index  offsets  when  required. 
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•  Node  Index  Offset.  These  8  bytes  are  an  unsigned  binary  that  identifies  the  zero- 
based  byte  offset  from  the  beginning  of  the  recording  file  to  the  point  in  the  file  at 
which  the  node  index  packet  sync  pattern  (0xEB25)  begins. 

•  Root  Index  Offset.  These  8  bytes  are  an  unsigned  binary  that  identifies  the  zero- 
based  byte  offset  from  the  beginning  of  the  recording  file  to  the  point  in  the  file  at 
which  the  previous  root  index  packet  in  its  chain  begins,  if  there  is  more  than  one  root 
index  packet  or  to  itself,  if  it  is  the  first  or  only  root  index  packet. 


f.  Node  Index  Packet  Entry  Format.  A  node  index  packet  contains  an  index  entry  or  entries 
using  the  format  shown  in  Table  1 1-29  and  Figure  11-39. 


Table  11-29.  General  Recording  Node  Index  Packet 

Packet  Header 

(Optional)  Packet  Secondary  Header 

Channel-Specific  Data 

(Optional)  Node  Index  File  Size 

Intra-Packet  Time  Stamp  for  Node  Index  I 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  I 

Recording  Node  Index  I 

Intra-Packet  Time  Stamp  for  Node  Index  2 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  2 

Recording  Node  Index  2 

Intra-Packet  Time  Stamp  for  Node  Index  N 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  N 

Recording  Node  Index  N 

Packet  Trailer 

msb 

Isb 

31  24 

23 

16 

15 

0 

Reserved 

Data  Type 

Channel  ID 

Data  Packet  Offset  (FSFW) 

Data  Packet  Offset  (MSFW) 

Figure  1 1-39.  Recording  Node  Index  Entry  Fayout 


•  (Optional)  Node  Index  File  Size.  These  8  bytes  are  an  unsigned  binary  that  identifies 
the  current  size  in  bytes  of  the  file  at  the  time  the  node  index  packet  was  created  and 
placed  into  the  recording.  This  value  should  be  the  same  as  the  node  index  offset. 

The  file  size  is  required  when  a  recording  is  split  across  multiple  media,  individual  or 
multiple  channels  are  split  from  the  original  recording  file,  or  time  slices  are  extracted 
from  the  original  recording.  In  all  cases  the  original  recording  file  size  will  allow 
recalculation  and/or  replacement  of  the  index  offsets  when  required. 

•  Channel  ID.  These  2  bytes  are  an  unsigned  binary  that  identifies  a  value  representing 
the  packet  channel  ID  for  the  data  packet  associated  with  this  node  index  item. 
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•  Data  Type.  This  byte  is  an  unsigned  binary  that  identifies  a  value  representing  the 
type  and  format  of  the  data  packet  associated  with  this  node  index  item. 

•  Data  Packet  Offset.  These  8  bytes  are  an  unsigned  binary  that  identifies  the  zero- 
based  byte  offset  from  the  beginning  of  the  recording  file  to  the  point  in  the  file  at 
which  the  data  packet  sync  pattern  (0xEB25)  begins  for  this  node  index  packet  item. 

1 1 .2.7.5  Computer-Generated  Data  Packets  Format  4,  Streaming  Configuration  Records 

Format  4  is  used  to  report  the  active  streaming  or  recording  configuration  of  the  system. 
The  organization  and  content  of  a  Format  4  Streaming  Configuration  record  is  indicated  in  the 
CSDW  FRMT  field. 

A  single  Streaming  Configuration  record  may  span  multiple  packets.  When  spanning 
occurs,  no  other  Format  4  Computer-Generated  Data  Packet  shall  be  interspersed,  although  other 
packet  types  are  permitted  between  segments  of  a  Format  4  packet.  When  spanning  multiple 
packets,  the  segments  shall  be  output  in  order,  and  the  last  segment  shall  be  flagged  in  the 
CSDW. 

a.  Format  4  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  Format  4  packet 
begins  with  the  CSDW,  which  is  formatted  as  shown  in  Figure  11-40. 


msb 

31 

16 

15 

14 

8 

7 

Isb 

0 

RESERVED 

FAST 

FRMT 

RCCVER 

Figure  1 1-40.  Computer-Generated  Format  4  Channel- Specific  Data  Word 


•  Reserved.  Bits  31-16  are  reserved. 

•  FRMT.  Bits  14-8  contain  the  streaming  configuration  record  format  according  to  the 
following  bit  patterns: 

000  0000  =  Complete  record  lAW  Chapter  9  ASCII  Format 
000  0001  =  Complete  record  lAW  Chapter  9  XMF  Format 
000  0010  =  Segmented  part  of  an  ASCII  Format  record 
000  0011  =  Segmented  part  of  an  XMF  Format  record 
000  0100  =  SHA2-256  Checksum 
000  0101  =  Currently  Selected  Channels 

•  FAST.  Bit  15  that  the  current  packet  is  the  last  packet  of  a  series  of  segmented 
packets.  Ignored  if  the  FRMT  bits  do  not  denote  a  segmented  record. 

0  =  The  current  packet  is  not  the  last  packet. 

1  =  The  current  packet  is  the  last  packet  in  a  segmented  series. 

•  RCC  106  Version  (RCCVER).  Bits  7-0  specify  which  RCC  release  version  applies 
and  to  which  the  following  recorded  data  complies  with.  The  value  shall  be 
represented  by  the  following  bit  patterns. 

0x00  through  OxOB  =  Reserved 

0x0C  =  RCC-106-17 

OxOD  through  OxFF  =  Reserved 
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Individual  Chapter  1 1  data  types  and  their  format/content  compliance  and 
applicability  with  the  RCC  release  version  are  defined  in  Subsection  1 1.2.1.1  item  e. 

b.  Full  or  Segmented  ASCII  or  XML  Format  Records.  Immediately  following  the  CSDW 
in  the  case  of  the  complete  or  segmented  versions  of  either  the  ASCII  or  XML  variants  of 
the  full  TMATS  configuration  record  shall  be  the  text  of  the  TMATS  record,  or  (if 
segmented)  the  text  that  immediately  sequentially  follows  the  last  character  of  the 
previous  segmented  part  of  the  TMATS  record. 

c.  SHA2-256  Checksum.  Immediately  following  the  CSDW  shall  be  32  bytes  containing 
the  binary  representation  of  the  256-bit  SHA2  checksum,  calculated  lAW  Chapter  6 
Subsection  6.2.3.1  l.f.  This  structure  is  shown  in  Table  11-30.  Note  that  Subsection 
6.2.3.1  l.f  and  the  Chapter  9  “G\SHA”  attribute  both  reference  hexadecimal 
representations  of  the  binary  value  used  in  this  record. 


Table  11-30.  SHA2-256  Checksum  Packet  Layout 

msb  Isb 

31  0 

Packet  Header 

Channel-Specific  Data  (Bits  31-0) 

Checksum  bits  255-224 

Checksum  bits  223-192 

Checksum  bits  191-160 

Checksum  bits  159-128 

Checksum  bits  127-96 

Checksum  bits  95-64 

Checksum  bits  63-32 

Checksum  bits  31-0 

Packet  Trailer 

To  avoid  confusion,  the  “big  endian”  format 
referenced  by  FIPS  180-2  shall  be  used.  Thus 
each  32  bit  portion  of  the  checksum  shown 
above  shall  be  treated  as  “big  endian”. 


d.  Currently  Selected  Channels.  Immediately  following  the  CSDW  shall  be  a  16-bit  count 
of  the  number  of  16 -bit  words  that  follow,  with  each  following  word  providing  the 
channel  ID  of  a  channel  currently  selected  (or  enabled)  for  output.  This  structure  is 
shown  in  Table  11-31.  The  order  of  the  channels  in  the  body  of  the  record  is 
implementation-dependent . 

Table  11-31.  Currently  Selected  Channel  Layout 

msb  Isb 

J5 _ 0_ 

Packet  Header _ 

Channel-Specific  Data  (Bits  15-0) 
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Channel- Specific  Data  (Bits  31-16) 


Number  of  Valid  Channels  to  follow 


Channel  ID  #1 


Channel  ID  #2 


Channel  ID  #n 


[  optional  filler  bytes  ] 


Packet  Trailer 


11.2.8  ARINC-429  Data  Packets 

1 1.2. 8.1  ARINC-429  Data  Packets,  Format  0 

Data  shall  be  packetized  in  word  mode:  each  32-bit  word  of  an  ARINC-429  bus  shall  be 
preceded  by  an  IPH  containing  an  IPDH  only  with  an  identifier  (ID  word)  that  provides  type  and 
status  information.  The  IPH  does  not  contain  an  IPTS.  The  packet  time  in  the  packet  header  is 
the  time  of  the  first  ARINC  data  word  in  the  packet,  and  the  time  of  successive  ARINC  data 
words  is  determined  from  the  first  word  time  using  the  gap  times  in  the  ID  words  that  precede 
each  of  the  data  words.  Multiple  words  of  multiple  ARINC-429  buses  can  be  inserted  into  a 
single  packet.  The  resultant  packets  shall  have  the  following  format  as  shown  in  Table  1 1-32. 


Table  11-32.  ARINC-429  Data  Packet  Format 

msb  Isb 

15  0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

Word  1  Intra-Packet  Data  Header 

Word  1  Intra-Packet  Data  Header 

ARINC-429  Data  Word  1  (Bits  15-0) 

ARINC-429  Data  Word  1  (Bits  31-16) 

Word  2  Intra-Packet  Data  Header 

Word  2  Intra-Packet  Data  Header 

ARINC-429  Data  Word  2  (Bits  15-0) 

ARINC-429  Data  Word  2  (Bits  31-16) 

Word  N  Intra-Packet  Data  Header 

Word  N  Intra-Packet  Data  Header 

ARINC-429  Data  Word  N  (Bits  15-0) 

ARINC-429  Data  Word  N  (Bits  31-16) 

Packet  Trailer 

NOTE^ 

Time  tagging  of  ARINC-429  shall 

correspond  to  the  first  data  bit  of  the 

r 

packet. 
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a.  ARINC-429  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each 
ARINC-429  data  packet  shall  begin  with  a  CSDW  formatted  as  shown  in  Figure  11-41. 


msb 

Isb 

31 

16 

15 

0 

RESERVED 

MSGCOUNT 

Figure  1 1-41.  ARINC-429  Packet  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-16  are  reserved 

•  Message  Count  (MSGCOUNT).  Bits  15-0  indicate  the  binary  value  of  the  number  of 
ARINC-429  words  included  in  the  packet. 

b.  Intra-Packet  Data  Header.  Bits  31-0  contain  the  ARINC-429  ID  word.  Each  ARINC- 
429  bus  data  word  is  preceded  by  an  ID  word  and  the  bit  definitions  are  as  shown  in 
Figure  11-42. 


msb 

31 

24 

23 

22 

21 

20 

19 

Isb 

0 

BUS 

EE 

PE 

BS 

R 

GAP  TIME 

Figure  1 1-42.  Intra-Packet  Data  Header  Format 


•  Bus.  Bits  31-24  indicate  a  binary  value  identifying  the  ARINC-429  bus  number 
associated  with  the  following  data  word.  The  first  bus  is  indicated  by  0.  A  maximum 
of  256  buses  can  be  placed  in  one  packet. 

•  Format  Error  (FE).  Bit  23  indicates  an  ARINC-429  format  error. 

0  =  No  format  error  has  occurred 
1  =  Eormat  error  has  occurred 

•  Parity  Error  (PE).  Bit  22  indicates  an  ARINC-429  parity  error. 

0  =  No  parity  error  has  occurred 
1  =  Parity  error  has  occurred 

•  Bus  Speed  (BS).  Bit  21  indicates  the  ARINC-429  bus  speed  the  data  is  from. 

0  =  Indicates  low-speed  ARINC-429  bus  (12.5  kHz) 

1  =  Indicates  high-speed  ARINC-429  bus  (100  kHz) 

•  Reserved  (R).  Bit  20  is  reserved. 

•  Gap  Time  (GAP  TIME).  Bits  19-0  contain  a  binary  value  that  represents  the  gap  time 
from  the  beginning  of  the  preceding  bus  word  (regardless  of  bus)  to  the  beginning  of 
the  current  bus  word  in  0. 1-ps  increments.  The  gap  time  of  the  first  word  in  the 
packet  is  GAP  TIME  =  0.  When  the  gap  time  is  longer  than  100  ms,  a  new  packet 
must  be  started. 

c.  ARINC-429  Packet  Data  Words.  The  data  words  shall  be  inserted  into  the  packet  in  the 

original  32-bit  format  as  acquired  from  the  bus. 
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11.2.9  Message  Data  Packets 


11.2.9.1  Message  Data  Packets,  Format  0 

The  data  from  one  or  more  separate  serial  communication  interface  channels  can  be 
placed  into  a  message  data  packet  (Table  11-33). 


Table  11-33.  Message  Data  Packet  Format 

msb  Isb 

\5 _ 0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 

Channel- Specific  Data  (Bits  31-16) 

_ Intra-Packet  Time  Stamp  for  Msg  1  (Bits  15-0) _ 

_ Intra-Packet  Time  Stamp  for  Msg  1  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  47-32) 

_ Intra-Packet  Time  Stamp  for  Msg  1  (Bits  63-48) _ 

Intra-Packet  Data  Header  for  Msg  1  (Bits  15-0) 


Intra-Packet  Data  Header  for  Msg  1  (Bits  31-16) 


Byte  2 

Byte  1 

Filler  (if  N  is  Odd) 

Byte  N 

Intra-Packet  Time  Stamp  for  Msg  N  (Bits  15-0) 
Intra-Packet  Time  Stamp  for  Msg  N  (Bits  31-16) 
Intra-Packet  Time  Stamp  for  Msg  N  (Bits  47-32) 
Intra-Packet  Time  Stamp  for  Msg  N  (Bits  63-48) 
Intra-Packet  Data  Header  for  Msg  N  (Bits  15-0) 


Intra-Packet  Data  Header  for  Msg  N  (Bits  31-16) 


Byte  2 

Byte  1 

Filler  (if  N  is  Odd) 

Byte  N 

Packet  Trailer 

a.  Message  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  message 
data  packet  begins  with  a  CSDW.  It  indicates  if  the  packet  body  contains  several  short 
messages  (type:  complete)  or  one  segment  of  a  long  message  (type:  segmented). 

b.  Complete  Message  Channel-Specific  Data  Word.  The  CSDW  is  formatted  for  the 
complete  type  of  packet  body  as  shown  in  Figure  11-43. 


msb 

Isb 

31 

18 

17  16 

15 

0 

RESERVED 

TYPE 

COUNTER 

Figure  1 1-43.  Complete  Message  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-18  are  reserved. 
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•  Type.  Bits  17-16  indicate  the  type  of  serial  packet. 

00  =  One  or  more  complete  messages 
01  =  Reserved 

10  =  Reserved 

11  =  Reserved 

•  Counter.  Bits  15-0  contain  a  binary  value  indicating  the  number  of  messages 
included  in  the  packet. 


c.  Segmented  Message  Channel-Specific  Data  Word.  The  CSDW  is  formatted  for  the 
segmented  type  of  packet  body  as  shown  in  Figure  11-44. 


msb 

Isb 

31 

18 

17  16 

15 

0 

RESERVED 

TYPE 

COUNTER 

Figure  1 1-44.  Segmented  Message  Channel- Specific  Data  Word 


•  Reserved.  Bits  31-18  are  reserved. 

•  Type.  Bits  17-16  indicate  the  type  of  serial  packet. 

00  =  Reserved 

01  =  Packet  is  a  beginning  of  a  long  message  from  a  single  source 

10  =  Whole  packet  is  the  last  part  of  a  long  message  from  a  single  source 

11=  Whole  packet  is  a  middle  part  of  a  long  message  from  a  single  source 

•  Counter.  Bits  15-0  contain  a  binary  value  indicating  the  segment  number  of  a  long 
message.  The  number  must  start  with  1  and  must  be  incremented  by  one  after  each 
packet.  The  maximum  length  of  a  single  long  message  is  4  gigabytes  (combined  with 
the  16-bit  Message  Length  field;  see  description  in  item  d  below). 

d.  Message  Data  Intra-Packet  Header.  After  the  channel-specific  data,  message  data  is 
inserted  into  the  packet.  Each  message  is  preceded  by  an  IPH  that  has  both  an  IPTS  and 
an  IPDH  containing  a  message  ID  word.  The  length  of  the  IPH  is  fixed  at  12  bytes  (96 
bits)  positioned  contiguously,  in  the  sequence  shown  in  Figure  11-45. 


Figure  1 1-45.  Message  Data  Intra-Packet  Header 


•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  message  data. 
First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following 
values. 

(3)  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  message  with  bits  31  to 
16  in  the  second  long  word  zero-filled;  or 
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(4)  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item 
g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags  (Subsection 
11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data  bit  in  the  message. 


•  Intra-Packet  Data  Header.  The  IPDH  is  an  identification  word  (message  ID  word) 
that  precedes  the  message  and  is  inserted  into  the  packet  with  the  format  shown  in 
Figure  11-46. 


msb 

31 

30 

29 

16 

15 
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DE 

EE 

SUBCHANNEE 

MESSAGE  EENGTH 

Figure  1 1-46.  Intra-Packet  Data  Header  Format 


•  Data  Error  (DE).  Bit  31  indicates  bad  data  bits  as  determined  by  parity,  checksums, 
or  cyclic  redundancy  check  words  received  with  the  data. 

0  =  No  data  error  has  occurred 
1  =  Data  error  has  occurred 

•  Format  Error  (FE).  Bit  30  indicates  a  protocol  error,  such  as  out-of-sequence  data  or 
length  errors. 

0  =  No  format  error 
1  =  Format  error  encountered 

•  Subchannel.  Bits  29-16  contain  a  binary  value  that  represents  the  subchannel  number 
belonging  to  the  message  that  follows  the  ID  word  when  the  channel  ID  in  the  packet 
header  defines  a  group  of  subchannels.  Zero  means  first  and/or  only  subchannel. 

•  Message  Length.  Bits  15-0  contain  a  binary  value  representing  the  length  of  the 
message  in  bytes  (n)  that  follows  the  ID  word.  The  maximum  length  of  a  message 
(complete)  or  a  message  segment  (segmented)  is  64  KB. 


11.2.10  Video  Packets 

11.2.10.1  Video  Packets,  Format  0  (Moving  Picture  Experts  Group-2/H.264) 

Format  0  Moving  Picture  Experts  Group  (MPEG) -2/H. 264  encoding  will  be  lAW 
Department  of  Defense  Motion  Imagery  Standards  Profile  (MISP)  Standard  9601.®  The  MPEG- 
2/H.264  format  will  be  transport  streams  (TS)  per  MISP  Recommended  Practice  (RP)  0101. 1.’ 
The  TS  will  be  encapsulated  at  a  constant  bit  rate  (CBR)  within  the  limits  of  MPEG-2  MP@ME 


®  Motion  Imagery  Standards  Board.  “Standard  Definition  Digital  Motion  Imagery,  Compression  Systems.”  STD 
9601  in  Motion  Imagery  Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015.2.  Retrieved  26 
April  2017.  Available  at  http://www.gwg. nga.mil/misb/docs/misp/MISP64. pdf. 

^  Motion  Imagery  Standards  Board.  “Use  of  MPEG-2  System  Streams  in  Digital  Motion  Imagery  Systems.”  RP 
0101.1.  27  January  2011.  Superseded  by  MISB  ST  1402.  Retrieved  26  April  2017.  Available  at 
http://www.gwg.nga.mi1/misb/docs/rp/RP0101.l.pdf 
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and  H.264  MP@L3  specifications  per  MISP  Recommended  Practice  9720d*  for  further 
standardization  and  telemeter/transmission  requirements  of  the  video. 

These  MPEG-2/H.264  algorithm  features  are  combined  to  produce  an  encoded  video 
stream  that  will  be  encapsulated  in  Format  0  packets.  The  H.264  can  be  carried  over  the  MPEG- 
2  TSs  using  International  Telecommunications  Union/Telecommunication  Standardization 
Sector  (ITU-T)  Recommendation  H. 222.0^  for  MPEG2  TS  containment  for  MPEG4  advanced 
video  codec.  The  MISP  has  adapted  this  with  9720d  and  9701. 

The  TSs  are  limited  to  a  single  program  stream  (PS)  using  program  elementary  stream 
(PES)  packets  that  share  the  same  common  time  base.  A  TS  must  contain  the  program 
association  table  (PAT)  and  program  map  table  (PMT)  that  define  the  program  ID  (PID)  for  the 
program  clock  reference  (PCR)  stream.  The  PSs  also  must  contain  at  least  one  packet  header. 

A  packet  with  Format  0  MPEG-2/H.264  video  data  has  the  basic  structure  shown  in 
Table  11-34.  Note  that  the  width  of  the  structure  is  not  related  to  any  number  of  bits.  This  figure 
is  merely  intended  to  represent  relative  placement  of  data  in  the  packet. 


Table  11-34.  General  MPEG-2/H.264  Video  Packet,  Format  0 

Packet  Header 

Channel-Specific  Data 

(Optional)  Intra-Packet  Header 

188-Byte  TS  Data 

(Optional)  Intra-Packet  Header 

188-Byte  TS  Data 

(Optional)  Intra-Packet  Time  Header 

188-Byte  TS  Data 

(Optional)  Intra-Packet  Time  Header 

188-Byte  TS  Data 

Packet  Trailer 

a.  Video  Packet  Audio.  When  recording  video  using  Format  0,  if  audio  is  present  it  will  be 
inserted  into  the  TS  per  ISO/IEC  13818-3^^  for  MPEG-2  and  ISO/IEC  14496-3'*  for 
H.264.  A  separate  analog  channel  to  specifically  record  audio  will  not  be  required  as 


^  Motion  Imagery  Standards  Board.  “Motion  Imagery  Systems  Matrix,  Standard  Definition  Motion  Imagery.”  RP 
9120d  in  Motion  Imagery  Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015.2.  Retrieved  26 
April  2017.  Available  at  http://www.gwg.nga.mil/misb/docs/misp/MISP64.pdf. 

^International  Telecommunications  Union  Telecommunication  Standardization  Sector.  Information  technology  - 
Generic  coding  of  moving  pictures  and  associated  audio  information:  Systems.  ITU-T  Rec.H. 222.0  (06/12).  June 
2012.  May  be  superseded  by  update.  Retrieved  27  April  2017.  Available  at  http://www.itu.int/rec/T-REC- 
H.222.0/en. 

International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
technology— Generic  coding  of  moving  pictures  and  associated  audio  information  —  Part  3,  Audio.  ISO/IEC  13818- 
3:1998.  Geneva:  International  Organization  for  Standardization,  1998. 

"  International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
Technology  -  Coding  of  Audio-Visual  Objects  -  Part  3:  Audio.  ISO/IEC  14496-3  ed  4.0.  Updated  by  ISO/IEC 
14496-3:2009.  Retrieved  26  April  2017.  Available  for  purchase  at 

http://webstore.iec.ch/Webstore/webstore.nsf/ArtNum  PK/43306!opendocument&preview=l. 
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MPEG-2/H.264  supports  audio  insertion  into  the  TS.  By  combining  video  and  audio, 
recording  bandwidth  and  memory  capacity  will  be  increased. 


b.  Video  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  Format  0 
packet  begins  with  the  CSDW,  formatted  as  shown  in  Figure  11-47. 
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Figure  1 1-47.  Video  Packet  Channel-Specific  Data  Word 


•  Embedded  Time  (FT).  Bit  3 1  indicates  if  embedded  time  is  present  in  the  MPEG-2 
video  data. 

0  =  No  embedded  time  present 
1  =  Embedded  time  is  present 

MPEG-2  stream  embedded  time  if  utilized  will  be  lAW  MISP  Standard  9708*^  and 
Standard  9715  Embedded  time  is  used  for  the  synchronization  of  core  MPEG-2 
data  when  extracted  from  the  Chapter  10  domain  (i.e.,  an  export  to  MPEG-2  files). 

•  Intra-Packet  Header.  Bit  30  indicates  if  IPTSs  are  inserted  before  each  transport 
packet. 

0  =  Intra-packet  times  not  present 
1  =  Intra-packet  times  present 

•  SCR/RTC  Sync  (SRS).  Bit  29  indicates  if  the  MPEG-2  SCR  is  RTC. 

0  =  SCR  is  not  synchronized  with  the  10  MHz  RTC 
1  =  SCR  is  synchronized  with  the  10  MHz  RTC 

The  TSs  contain  their  own  embedded  time  base  used  to  facilitate  the  decoding  and 
presentation  of  video  and/or  audio  data  at  the  decoder.  Within  a  PS,  all  streams  are 
synchronized  to  a  single  time  source  referred  to  as  the  system  clock  reference  (SCR). 
Within  a  TS,  each  embedded  program  contains  its  own  PCR,  requiring  that  each 
Format  0-encoded  MPEG-2/H.264  TS  contains  only  a  single  program  allowing  each 
format  to  be  treated  in  a  similar  manner  using  a  single  global  clocking  reference. 

The  10  MHz  RTC  is  for  the  purposes  of  synchronizing  and  time-stamping  the  data 
acquired  from  multiple  input  sources.  For  input  sources  that  don’t  define  an  explicit 
timing  model  for  data  presentation,  superimposing  this  timing  model  can  be 
accomplished.  For  MPEG-2/H.264,  however,  an  explicit  synchronization  model 
based  on  a  27  MHz  clock  is  defined  for  the  capture,  compression,  decompression,  and 
presentation  of  MPEG-2/H.264  data.  In  order  to  relate  the  two  different  timing 
models,  the  MPEG-2/H.264  SCR/PCR  time  stamps  (if  enabled)  will  be  derived  from 


Motion  Imagery  Standards  Board.  “Imbedded  Time  Reference  for  Motion  Imagery  Systems.”  STD  9708  in 
Motion  Imagery  Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015.2.  Retrieved  26  April 
2017.  Available  at  httr)://www. gwg.nga.mil/misb/docs/misp/MISP64. pdf. 

Motion  Imagery  Standards  Board.  “Time  Reference  Synchronization.”  STD  9715  in  Motion  Imagery  Standards 
Profde.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015.2.  Retrieved  26  April  2017.  Available  at 
http://www.gwg.nga.mil/misb/docs/misp/MISP64.pdf. 
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the  10-MHz  RTC  timing  reference  source  (by  generating  the  27 -MHz  MPEG- 
2/H.264  reference  clock  slaved  to  the  10-MHz  RTC). 

MPEG-2/H.264  defines  the  SCR/PCR  time  stamp  as  a  42-bit  quantity,  consisting  of  a 
33-bit  base  value  and  a  9-bit  extension  value.  The  exact  value  is  defined  as: 

SCR  =  SCR_base  *  300  -r  SCR_ext 

where: 


SCR_base=  [(system_clock_frequency  *  t)  7300]  MOD  233 

SCR_ext  =  [(system_clock_frequency  *  t)  71]  MOD  300 

Eor  recording  periods  of  less  than  26.5  hours,  the  SCR  can  be  directly  converted  into 
the  10-MHz  RTC  using  the  equation: 

10-MHz  RTC  time  base  =  SCR  *  10727  (rounded  to  nearest  integer) 

Eor  recording  periods  longer  than  this,  the  Eormat  0  packet  header  time  stamp  can  be 
used  to  determine  the  number  of  times  the  MPEG-27H.264  SCR  has  rolled  over  and 
calculate  the  upper  8  bits  of  the  free-running  counter’s  value. 

•  Key-Eength- Value.  Bit  28  indicates  if  key-length-value  (KEV)  metadata  is  present  in 
the  MPEG-2  video  data. 

0  =  No  KEV  metadata  present 
1  =  KEV  metadata  is  present 


MPEG-27H.264  stream  KEV  metadata,  if  utilized,  will  be  lAW  the  following  MISP 
documents: 

o  Standard  97 11 

o  Standard  9712'^ 

o  Standard  97 13 

o  Recommended  Practice  9717^^ 

o  Standard  0107.1.'* 


Motion  Imagery  Standards  Board.  “Intelligence  Motion  Imagery  Index,  Geospatial  Metadata.”  STD  9711  in 
Motion  Imagery  Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015.2.  Retrieved  26  April 
2017.  Available  at  http://vv'vv'vv'. gwg.nga.mil/misb/docs/misp/MISP64.pdf. 

Motion  Imagery  Standards  Board.  “Intelligence  Motion  Imagery  Index,  Content  Description. . .”  STD  97 12  in 
Motion  Imagery  Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015.2.  Retrieved  26  April 
2017.  Available  at  http://www.gwg.nga.mil/misb/docs/misp/MISP64.pdf. 

Motion  Imagery  Standards  Board.  “Data  Encoding  Using  Key-Length-Value.”  STD  9713  in  Motion  Imagery 
Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015.2.  Retrieved  26  April  2017.  Available  at 
http://www.gwg.nga.mil/misb/docs/misp/MISP64.pdf. 

Motion  Imagery  Standards  Board.  “Packing  KLV  Packets  into  MPEG-2  Systems  Streams.”  RP  9717  in  Motion 
Imagery  Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015.2.  Retrieved  26  April  2017. 
Available  at  http://www.gwg.nga.mil/misb/docs/misp/MISP64.pdf. 

Motion  Imagery  Standards  Board.  Bit  and  Byte  Order  for  Metadata  in  Motion  Imagery  Files  and  Streams.  STD 
107.1.  June  2011.  Updated  by  STD  107.2.  Retrieved  26  April  2017.  Available  at 
http://www.gwg.nga.mi1/misb/docs/standards/ST0107.l.pdf. 
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•  Payload  (PL).  Bits  27-24  indicate  the  payload  type  within  the  MPEG-2  stream  per 
MISP  Xon2.^‘^ 

0000  =  MPEG-2  MP  @  ME 
0001  =H.264  MP  @  E2.1 
0010  =  H.264  MP  @  E2.2 
0011  =H.264  MP  @  E3 
0100-11 11=  Reserved. 

•  Byte  Alignment  (BA).  Bit  23  indicates  the  MPEG-2  data  payload  byte  alignment 
within  16-bit  words. 


0  =  Eittle-endian  as  referenced  in  Eigure  11-48. 
1  =  Big-endian  as  referenced  in  Eigure  11-49. 
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TS  Sync  Byte  (Bits  0  to  7) 

TS  Data  (Bits  8  to  15) 

TS  Data  (Bits  16  to  23) 

TS  Data  (Bits  24  to  31) 

TS  Data  (Bits  1488  to  1495) 

TS  Data  (Bits  1496  to  1503) 

Eigure  1 1-48.  Eormat  0  MPEG-2/H.264  Video  Erame  Eormat,  16-Bit 


Eittle-Endian  Aligned 
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TS  Data  (Bits  8  to  15) 

TS  Sync  Byte  (Bits  0  to  7) 

TS  Data  (Bits  24  to  31) 

TS  Data  (Bits  16  to  23) 

TS  Data  (Bits  1496  to  1503) 

TS  Data  (Bits  1488  to  1495) 

Eigure  1 1-49.  Eormat  0  MPEG-2/H.264  Video  Erame  Eormat,  16-Bit  Big- 

Endian  (Native)  Aligned 


•  Reserved.  Bits  22-0  are  reserved. 

c.  Intra-Packet  Header.  If  enabled,  the  IPH  shall  include  a  64-bit  IPTS,  which  is  inserted 
immediately  before  the  TS  sync  pattern.  The  length  of  the  IPH  is  fixed  at  8  bytes  (64 
bits)  positioned  contiguously,  in  Eigure  11-50. 

msb  Isb 

^1 _ 0_ 

Time  (ESEW) _ 

Time  (MSEW) _ 

Eigure  1 1-50.  Video  Packet,  Eormat  0  Intra-Packet  Header 


Motion  Imagery  Standards  Board.  “Xon2”.  Subsection  D-l. 2  in  Motion  Imagery  Standards  Profile.  MISP  6.4.  4 
October  2012.  Updated  by  MISP-2015.2.  Retrieved  26  April  2017.  Available  at 
http :  //WWW .  gwg .  n  ga .  mil/mi  sb/doc  s/mi  sp/MI  S  P64 .  pdf . 
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•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  individual  TS 
packets.  First  long  word  (LSLW)  bits  31-0  and  second  long  word  (MSLW)  bits  31-0 
indicate  the  following  values. 

(5)  The  48-bit  RTC  that  will  correspond  to  the  first  bit  of  the  TS.  Bits  31  to  16  in  the 
second  long  word  (MSLW)  will  be  zero  filled;  or 

(6)  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item 
g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags  (Subsection 
11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  bit  of  the  TS. 

d.  Video  Packet  Data.  A  Format  0  packet  shall  contain  an  integral  number  of  188-byte 
(1504  bits)  TS  packets  as  illustrated  in  Figure  1 1-48  and  Figure  11-49  depending  on  the 
byte  alignment  bit.  The  IPHs  can  be  inserted  in  Format  0  video  data  packets.  The 
10  MHz  RTC  packet  header  time  is  the  time  of  the  first  bit  of  the  first  TS  in  the  packet. 


The  CBR  of  the  encoding  will  be  user- selectable  and  within  the  MPEG-2  MP@ML  and 
H.264  MP@L3  specification.  Per  ISO/IEC  13818-1:2007^°  the  TS  format  will  be  fixed-length 
188-byte  (1504  bits)  frames  containing  an  8-bit  sync  pattern  or  “sync  byte”  (starting  at  bit  0  and 
ending  at  bit  7  of  the  TS  format).  The  sync  b3Tes  value  is  010001 1 1  (0x47).  The  rest  of  the  TS 
187  data  bytes  will  follow  (Table  11-35). 


Table  11-35.  Format  0  MPEG-2/H.264  Video  Data  Packet 

(Example  is  16-Bit  Aligned) 

msb  Isb 

15  0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp 

TS  Sync  Byte  Data  (Bits  15  to  0) 

TS  Data  (Bits  31  to  16) 

TS  Data  (Bits  1487  to  1472) 

TS  Data  (Bits  1503  to  1488) 

(Optional)  Intra-Packet  Time  Stamp 

TS  Sync  Byte  Data  (Bits  15  to  0) 

TS  Data  (Bits  31  to  16) 

TS  Data  (Bits  1487  to  1472) 

TS  Data  (Bits  1503  to  1488) 

International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
technology  —  Generic  coding  of  moving  pictures  and  associated  audio  information:  Systems.  ISO/IEC  13818- 
1:2007.  October  2007.  Updated  by  ISO/IEC  13818-1:2013.  Retrieved  26  April  2017.  Available  for  purchase  at 
https://www.iso.org/standard/62074.html. 
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_ (Optional)  Intra-Packet  Time  Stamp 

Repeat  for  each  TS. 


Packet  Trailer 


11.2.10.2  Video  Packets,  Format  1  (ISO  13818-1  MPEG-2  Bit  Stream) 

Unlike  Video  Packets,  Format  0  (MPEG-2)  the  Format  1  packets  encapsulate  the 
complete  ISO/IEC  13818-1:2007  bit  streams  for  both  program  and  transport  with  constant  or 
variable  bit  rates.  Also  any  of  the  profiles  and  level  combinations  as  set  forth  by  ISO/IEC 
13818-1:2007  may  be  utilized  in  the  encoding  process.  The  TSs  are  limited  to  a  single  PS  using 
PES  packets  that  share  the  same  common  time  base.  A  TS  must  contain  the  PAT  and  PMT  that 
define  the  PID  for  the  PCR  stream.  The  PSs  also  must  contain  at  least  one  packet  header. 

a.  MPEG-2  Stream  Packet  Body.  The  Format  1  packet  within  MPEG-2  packets  has  the 
basic  structure  shown  in  Table  11-36.  Note  that  the  width  of  the  structure  is  not  related  to 
any  number  of  bits.  This  drawing  is  merely  intended  to  represent  relative  placement  of 
data  in  the  packet. 

Table  11-36.  General  MPEG-2  Video  Packet,  Format  1 

Packet  Header 
Channel-Specific  Data 
(Optional)  Intra-Packet  Header 
MPEG-2  Packet  I 
(Optional)  Intra-Packet  Header 
MPEG-2  Packet  2 


(Optional)  Intra-Packet  Header 
MPEG- 2  Packet  n 
Packet  Trailer 


b.  Video  Packet  Audio.  When  recording  video  using  Format  1,  if  audio  is  present,  it  will  be 
inserted  into  the  TS  per  ISO/IEC  I38I8-3.  A  separate  analog  channel  to  specifically 
record  audio  will  not  be  required  as  MPEG-2  supports  audio  insertion  into  the  TS  or  PS. 
By  combining  video  and  audio,  recording  bandwidth  and  memory  capacity  will  be 
increased. 


c.  MPEG-2  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  MPEG-2  bit 
stream  begins  with  a  CSDW  formatted  as  shown  in  Figure  11-51. 
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Figure  11-51.  MPEG-2  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-22  are  reserved  for  future  use. 

•  KEV.  Bit  21  indicates  if  KEV  metadata  is  present  in  the  MPEG-2  video  data. 
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0  =  No  KLV  metadata  present 
1  =  KLV  metadata  is  present. 

MPEG-2  stream  KLV  metadata  (if  utilized)  will  be  lAW  MISP  Standard  9711, 
Standard  9712,  Standard  9713,  Recommended  Practice  9717,  and  Standard  0107.1. 

•  SCR/RTC  Sync  (SRS).  Bit  20  indicates  whether  the  MPEG-2  SCR  is  RTC. 

0  =  SCR  is  not  synchronized  with  the  10  MHz  RTC. 

1  =  SCR  is  synchronized  with  the  10  MHz  RTC. 

The  TSs  contain  their  own  embedded  time  base  used  to  facilitate  the  decoding  and 
presentation  of  video  and/or  audio  data  at  the  decoder.  Within  a  PS,  all  streams  are 
synchronized  to  a  single  SCR.  Within  a  TS,  each  embedded  program  contains  its 
own  PCR,  requiring  that  each  Eormat  1  encoded  MPEG-2  TS  contain  only  a  single 
program  allowing  each  format  to  be  treated  in  a  similar  manner  using  a  single  global 
clocking  reference. 

The  10  MHz  RTC  is  used  to  synchronize  and  time  stamp  the  data  acquired  from 
multiple  input  sources.  Eor  input  sources  that  don’t  define  an  explicit  timing  model 
for  data  presentation,  superimposing  this  timing  model  can  be  accomplished.  Eor 
MPEG-2,  however,  an  explicit  synchronization  model  based  on  a  27  MHz  clock  is 
defined  for  the  capture,  compression,  decompression,  and  presentation  of  MPEG-2 
data.  In  order  to  relate  the  two  different  timing  models,  the  MPEG-2  SCR/PCR  time 
stamps  (if  enabled)  will  be  derived  from  the  10  MHz  RTC  timing  reference  source 
(by  generating  the  27  MHz  MPEG-2  reference  clock  slaved  to  the  10  MHz  RTC). 

MPEG-2  defines  the  SCR/PCR  time  stamp  as  a  42-bit  quantity,  consisting  of  a  33-bit 
base  value  and  a  9-bit  extension  value.  The  exact  value  is  defined  as: 

SCR  =  SCR_base  *  300  -t  SCR_ext 


where: 

SCR_base=  ((system_clock_frequency  *  t)/300)  MOD  233 
SCR_ext=  ((system_clock_frequency  *  t)/l)  MOD  300 

Eor  recording  periods  of  less  than  26.5  hours,  the  SCR  can  be  directly  converted  into 
the  10  MHz  RTC  using  the  equation: 

10  MHz  RTC  time  base  =  SCR  *  10/27  (rounded  to  the  nearest  integer) 

Eor  recording  periods  longer  than  this,  the  Eormat  1  packet  header  time  stamp  can  be 
used  to  determine  the  number  of  times  the  MPEG-2  SCR  has  rolled  over  and 
calculate  the  upper  8  bits  of  the  free-running  counter’s  value. 

•  Intra-Packet  Header  (IPH).  Bit  19  indicates  whether  IPTSs  are  inserted  before  each 
program  or  transport  packet. 

•  Encoding  Profile  and  Level  (EPL).  Bits  18-15  indicate  the  MPEG-2  profile  and  level 
of  the  encoded  bit  stream. 

0000  =  Simple  Profile  @  Main  Level 
0001  =  Main  Profile  @  Low  Level 
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0010  =  Main  Profile  @  Main  Level 
0011=  Main  Profile  @  High- 1440  Level 
0100  =  Main  Profile  @  High  Level 
0101  =  SNR  Profile  @  Low  Level 
0110  =  SNR  Profile  @  Main  Level 
0111  =  Spatial  Profile  ©High- 1440  Level 

1000  =  High  Profile  @  Main  Level 

1001  =  High  Profile  @  High- 1440  Level 

1010  =  High  Profile  @  High  Level 

1011  =  4:2:2  Profile  @  Main  Level 
1100  =  Reserved 

1101=  Reserved 
1110  =  Reserved 
1111=  Reserved 

•  Embedded  Time  (ET).  Bit  14  indicates  whether  embedded  time  is  present  in  the 
MPEG-2  video  data. 

0  =  No  embedded  time  present 
1  =  Embedded  time  is  present 

MPEG-2  stream  embedded  time,  if  utilized,  will  be  lAW  MISP  Standard  9708  and 
Standard  9715.  Embedded  time  is  used  for  the  synchronization  of  core  MPEG-2  data 
when  extracted  from  the  Chapter  10  domain  (i.e.,  an  export  to  MPEG-2  files). 

•  Mode  (MD).  Bit  13  indicates  whether  the  MPEG-2  bit  stream  was  encoded  using  a 
variable  or  CBR  parameter  setting. 

0  =  CBR  stream 
1  =  Variable  bit  rate  stream 

•  Type  (TP).  Bit  12  indicates  the  type  of  data  the  packetized  MPEG-2  bit  stream 
contains. 

0  =  Transport  data  bit  stream 
1  =  Program  data  bit  stream 

•  Packet  Count  (PC).  Bits  11-0  indicate  the  binary  value  of  the  number  of  MPEG-2 
packets  included  in  the  Eormat  1  packet. 

An  integral  number  of  complete  packets  will  be  in  each  Eormat  1  packet.  If  the 
MPEG-2  hardware  implementation  is  unable  to  determine  the  value  of  this  number, 
the  value  of  0  is  used  by  default.  If  TYPE  =  0,  then  this  number  represents  the 
number  of  TS  packets  within  the  Eormat  1  packet.  If  TYPE  =  1,  then  this  number 
represents  the  number  of  PS  packs  within  the  Eormat  1  packet. 

d.  Intra-Packet  Header.  If  enabled,  the  IPH  shall  include  a  64-bit  IPTS,  which  is  inserted 
immediately  before  the  MPEG-2  packet  (transport  or  program).  The  length  of  the  IPH  is 
fixed  at  64  bits  (8  bytes)  positioned  contiguously,  in  the  following  sequence  (Figure 
11-52). 
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Time  (LSLW) 

Time  (MSLW) 

Figure  11-52.  Video  Packet,  Format  1  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  individual 
MPEG-2  packets  (transport  or  program).  First  long  word  (LSLW)  bits  31-0  and 
second  long  word  (MSLW)  bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  will  correspond  to  the  first  bit  of  the  MPEG-2  packet 
(transport  or  program).  Bits  31  to  16  in  the  second  long  word  (MSLW)  will 
be  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  Time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  bit  of 
the  MPEG-2  packet  (transport  or  program). 

1 1 .2. 10.3  Video  Packets,  Lormat  2  (ISO  14496  MPEG-4  Part  10  AVC/H.264) 

Lormat  2  video  encoding  will  be  lAW  ISO  14496  Part  10.^'  The  carrier  format  for 
Lormat  2  AVC/H.264  will  be  ISO/IEC  13818-1:2007  bit  streams  for  both  program  and  transport 
with  constant  or  variable  bit  rates.  AVC/H.264  can  be  carried  over  the  MPEG-2  streams  lAW 
ITU-T  Rec.  H.222.0. 

Unlike  Lormat  0  video  packets  (MPEG-2/H.264),  which  only  support  a  fixed  MPEG-2 
transport  and  fixed  MPEG-2/H.264  profiles  and  levels,  the  Lormat  2  AVC/H.264  packets 
encapsulate  the  complete  MPEG-2  TSs/PSs,  provide  for  a  fixed/variable  bit  rate  (Lormat  1),  and 
include  all  H.264  video  encoding  profiles  and  levels. 

Lormat  2  AVC/H.264  streams  are  limited  to  a  single  program  or  TS  using  PES  packets 
that  share  the  same  common  time  base.  The  TS  or  PS  must  contain  the  PAT  and  PMT  that 
define  the  PID  for  the  PCR  stream.  The  PSs  also  must  contain  at  least  one  packet  header. 

a.  AVC/H.264  Stream  Packet  Body.  The  Lormat  2  packet  within  AVC/H.264  packets  has 
the  basic  structure  shown  in  Table  11-37.  Note  that  the  width  of  the  structure  is  not 
related  to  any  number  of  bits.  This  drawing  is  merely  intended  to  represent  relative 
placement  of  data  in  the  packet. 

Table  11-37.  General  AVC/H.264  Video  Packet,  Format  2 

Packet  Header 
Channel-Specific  Data 
(Optional)  Intra-Packet  Header 
AVC/H.264  Packet  1 


Isb 

0 


International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
Technology  -  Coding  of  Audio-Visual  Objects  -  Part  10:  Advanced  Video  Coding.  ISO/IEC  14496-10:2012.  April 
2012.  May  be  superseded  by  update.  Retrieved  26  April  2017.  Available  at 
http://standards.iso.org/ittf/PubliclvAvailableStandards/index.html. 
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(Optional)  Intra-Packet  Header 


AVC/H.264  Packet  2 


(Optional)  Intra-Packet  Header 


AVC/H.264  Packet  n 


Packet  Trailer 


b.  Video  Packet  Audio.  When  recording  video  using  Format  2  AVC/H.264,  if  audio  is 
present  it  will  be  inserted  into  the  TS  per  ISO/IEC  13818-3  or  13818-7.^^  A  separate 
analog  channel  to  specifically  record  audio  will  not  be  required  as  AVC/H.264  supports 
audio  insertion  into  the  AVC/H.264  TS.  By  combining  video  and  audio,  recording 
bandwidth  and  memory  capacity  will  be  increased. 

c.  AVC/H.264  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  AVC/H.264 
packet  begins  with  a  CSDW  formatted  as  shown  in  Figure  11-53. 
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Figure  1 1-53.  AVC/H.264  Channel-Specific  Data  Word 


•  Reserved  (R).  Bits  31-27  are  reserved  for  future  use. 

•  AVC/H.264  Audio  Encoding  Type  (AET).  Bit  26  indicates  the  AVC/H.264  audio 
encoding  type. 

0  =  ISO/IEC  13818-3 
1  =  ISO/IEC  I38I8-7 

•  AVC/H.264  Encoding  Eevel  (EE).  Bits  25-22  indicate  the  AVC/H.264  level  of  the 
encoded  video  bit  stream. 


0000  =  1 

0001  = 

lb 

0010=  1.1 

0011  = 

1.2 

0100=  1.3 

0101  =  2 

0110  = 

2.1 

0111  =  2.2 

1000  = 

3 

1001  =  3.1 

1010  =  3.2 

1011  = 

4 

1100  =  4.1 

1101  = 

4.2 

1110  =  5 

nil  =  5.1 

•  KEV.  Bit  21  indicates  if  KEV  metadata  is  present  in  the  MPEG-2  video  data. 

0  =  No  KEV  metadata  present 
1  =  KEV  metadata  is  present 

MPEG-2  stream  KEV  metadata  (if  utilized)  will  be  lAW  MISP  Standard  9711, 
Standard  9712,  Standard  9713,  Recommended  Practice  9717,  and  Standard  0107.1. 

•  SCR/RTC  Sync  (SRS).  Bit  20  indicates  whether  the  AVC/H.264  MPEG-2  SCR  is 
RTC. 


International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
technology  —  Generic  coding  of  moving  pictures  and  associated  audio  information  —  Part  7:  Advanced  Audio 
Coding  (AAC).  ISO/IEC  13818-7:2006(E).  Geneva:  International  Organization  for  Standardization,  2006. 
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0  =  SCR  is  not  synchronized  with  the  10  MHz  RTC. 

1  =  SCR  is  synchronized  with  the  10  MHz  RTC. 

The  TSs  contain  their  own  embedded  time  base  used  to  facilitate  the  decoding  and 
presentation  of  video  and/or  audio  data  at  the  decoder.  Within  a  PS,  all  streams  are 
synchronized  to  a  single  SCR.  Within  a  TS,  each  embedded  program  contains  its 
own  PCR,  requiring  that  each  Format  0-encoded  MPEG-2  TS  contain  only  a  single 
program  allowing  each  format  to  be  treated  in  a  similar  manner  using  a  single  global 
clocking  reference. 

The  10-MHz  RTC  is  provided  to  synchronize  and  time  stamp  the  data  acquired  from 
multiple  input  sources.  For  input  sources  that  don’t  define  an  explicit  timing  model 
for  data  presentation,  superimposing  this  timing  model  can  be  accomplished.  For 
MPEG-2,  however,  an  explicit  synchronization  model  based  on  a  27  MHz  clock  is 
defined  for  the  capture,  compression,  decompression,  and  presentation  of  MPEG-2 
data.  In  order  to  relate  the  two  different  timing  models,  the  MPEG-2  SCR/PCR  time 
stamps  (if  enabled)  will  be  derived  from  the  10  MHz  RTC  timing  reference  source 
(by  generating  the  27  MHz  MPEG-2  reference  clock  slaved  to  the  10  MHz  RTC). 

MPEG-2  defines  the  SCR/PCR  time  stamp  as  a  42-bit  quantity,  consisting  of  a  33-bit 
base  value  and  a  9-bit  extension  value.  The  exact  value  is  defined  as: 

SCR  =  SCR_base  *  300  -t  SCR_ext 

where: 


SCR_base=  [(system_clock_frequency  *  t)/300]  MOD  233 

SCR_ext  =  [(system_clock_frequency  *  t)/l]  MOD  300 

For  recording  periods  of  less  than  26.5  hours,  the  SCR  can  be  directly  converted  into 
the  10  MHz  RTC  using  this  equation: 

10  MHz  RTC  time  base  =  SCR  *  10/27  (rounded  to  nearest  integer). 

For  recording  periods  longer  than  this,  the  Format  0  packet  header  time  stamp  can  be 
used  to  determine  the  number  of  times  the  MPEG-2  SCR  has  rolled  over  and 
calculate  the  upper  8  bits  of  the  free-running  counter’s  value. 

Intra-Packet  Header  (IPH).  Bit  19  indicates  whether  IPTSs  are  inserted  before  each 
program  or  transport  packet. 

AVC/H.264  Encoding  Profile  (EP).  Bits  18-15  indicate  the  AVC/H.264  profile  of  the 
encoded  video  bit  stream. 

0000  =  Baseline  Profile  (BP)  0001  =  Main  Profile  (MP) 

0010  =  Extended  Profile  (EP)  0011  =  High  Profile  (HiP) 

0100  =  High  10  Profile  (HilOP)  0101  =  High  4:2:2  Profile  (Hi422P) 

01 10  =  High  4:4:4  Profile  (Hi444P)  0111-1111  =  Reserved 

Embedded  Time  (FT).  Bit  14  indicates  whether  embedded  time  is  present  in  the 
AVC/H.264  MPEG-2  video  data. 

0  =  No  embedded  time  present 
1  =  Embedded  time  is  present 
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AVC/H.264  MPEG-2  stream  embedded  time  (if  utilized)  will  be  lAW  MISP  Standard 
9708  and  Standard  9715.  Embedded  time  is  used  for  the  synchronization  of  core 
AVC/H.264  data  when  extracted  from  the  Chapter  10  domain,  i.e.,  an  export  to 
AVC/H.264  files. 

•  Mode  (MD).  Bit  13  indicates  whether  the  AVC/H.264  MPEG-2  bit  stream  was 
encoded  using  a  variable  or  CBR  parameter  setting. 

0  =  CBR  stream 

1  =  Variable  bit  rate  stream 

•  Type  (TP).  Bit  12  indicates  the  type  of  data  the  packetized  AVC/H.264  MPEG-2  bit 
stream  contains. 

0  =  Transport  data  bit  stream 

1  =  Program  data  bit  stream 

•  Packet  Count  (PC).  Bits  1 1-0  indicate  the  binary  value  of  the  number  of  AVC/H.264 
packets  included  in  the  Eormat  2  packet. 

An  integral  number  of  complete  packets  will  be  in  each  Eormat  2  packet.  If  the 
AVC/H.264  hardware  implementation  is  unable  to  determine  the  value  of  this 
number,  the  value  of  0  is  used  by  default.  If  TYPE  =  0,  then  this  number  represents 
the  number  of  TS  packets  within  the  Eormat  2  packet.  If  TYPE  =  I,  then  this  number 
represents  of  the  number  of  PS  packets  within  the  Eormat  2  packet. 

d.  Intra-Packet  Header.  If  enabled,  the  IPH  shall  include  a  64-bit  IPTS,  which  is  inserted 
immediately  before  the  AVC/H.264  packet  (transport  or  program).  The  length  of  the  IPH 
is  fixed  at  8  bytes  (64  bits)  positioned  contiguously,  in  the  following  sequence  (Figure 
11-54). 

msb 

^1 _ 

Time  (ESEW) 

Time  (MSEW) 

Figure  1 1-54.  Video  Packet,  Format  2  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  individual 
AVC/H.264  packets  (transport  or  program).  First  long  word  (ESEW)  bits  31-0  and 
second  long  word  (MSEW)  bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  will  correspond  to  the  first  bit  of  the  AVC/H.264  packet. 
Bits  31  to  16  in  the  second  long  word  (MSEW)  will  be  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  1 1.2. 1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  bit  of 
the  AVC/H.264  packet. 


Isb 
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1 1 .2. 10.4  Video  Packets,  Format  3  (MJPEG) 

Format  3  video  encoding  will  be  lAW  ISO/IEC  10918  Part  l^^used  by  Audio  Video 
Interleaved,  Motion  JPEG  Video.  A  set  of  images  for  this  type  with  compatible  parameters  can 
be  placed  into  an  MJPEG  video  packet  as  shown  in  Table  11-38.  Erame  headers  shall  be  limited 
to  those  specified  in  ISO/IEC  10918  Part  1.  These  types  are  SOEO,  SOEl,  SOP2,  SOP3,  SOP9, 
SOEIO,  and  SOEl  1.  Of  these  types  accommodated,  this  specification  provides  implementation 
only  for  baseline  sequential  discrete  cosine  transform. 


Table  11-38.  MJPEG  Video  Packet,  Format  3 


msb  Isb 

25 _ 0 

_ PACKET  HEADER _ 

_ CHANNEE-SPECIEIC  DATA  (BITS  15-0) _ 

_ CHANNEE-SPECIEIC  DATA  (BITS  31-16) _ 

INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  15-0) 

_ INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  31-16) _ 

_ INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  47-32) _ 

_ INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  63-48) _ 

INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  79-64) 


INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  95-80) 


ERAME  BYTE  2 

ERAME  BYTE  1 

; 

; 

EIEEER  (IE  n  IS  ODD) 

ERAME  BYTE  n 

INTRA-PACKET  HEADER  EOR  SEGMENT  n  (BITS  15-0) 
INTRA-PACKET  HEADER  EOR  SEGMENT  n  (BITS  31-16) 
INTRA-PACKET  HEADER  EOR  SEGMENT  n  (BITS  47-32) 
INTRA-PACKET  HEADER  EOR  SEGMENT  n  (BITS  63-48) 
INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  79-64) 


INTRA-PACKET  HEADER  EOR  SEGMENT  n  (BITS  95-80) 


ERAME  BYTE  2 

ERAME  BYTE  1 

; 

; 

EIEEER  (IE  n  IS  ODD) 

ERAME  BYTE  n 

PACKET  TRAIEER 


An  MJPEG  video  packet  shall  contain  one  or  more  fixed- length  segments  of  a  partial 
MJPEG  frame,  one  complete  MJPEG  frame,  or  multiple  complete  MJPEG  frames. 


MJPEG  video  packet  information  will  be  specified  in  the  CSDW. 


International  Organization  for  Standardization/International  Electrotechnical  Commission.  “General  sequential 
and  progressive  syntax”.  Annex  B,  section  B.2,  in  Information  technology  —  Digital  compression  and  coding  of 
continuous-tone  still  images:  Requirements  and  guidelines.  ISO/IEC  10918-1:1994.  May  be  superseded  by  update. 
Geneva:  International  Organization  for  Standardization,  1994. 
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a.  MJPEG  Video  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each 
MJPEG  video  packet  begins  with  a  CSDW.  It  indicates  if  the  packet  body  contains 
several  complete  images  or  partial  images  (Eigure  11-55). 


msb 

Isb 
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RESERVED 

Eigure  1 1-55.  MJPEG  Video  packet  Channel-Specific  Data  Word 


•  Parts.  Bits  31-30  indicate  which  segment  of  the  frames  is  contained  in  the  packet  if 
the  packet  does  not  contain  one  or  more  complete  frames. 

00  =  Packet  does  not  contain  first  or  last  segment  of  frame 
01  =  Packet  contains  first  segment  of  frame 

10  =  Packet  contains  last  segment  of  frame 

11  =  Reserved 

•  Sum.  Bits  29-28  indicate  if  the  packet  contains  a  partial  frame  that  spans  multiple 
packets,  one  complete  frame,  or  multiple  complete  frames. 

00  =  Packet  contains  less  than  one  complete  frame  (a  segment) 

01  =  Packet  contains  one  complete  frame 

10  =  Packet  contains  multiple  complete  frames 

11  =  Reserved 

•  Intra-Packet  Header  (IPH).  Bit  27  indicates  that  the  IPH  (time  stamp/data)  shall 
precede  each  complete  frame  within  a  packet  or  the  first  segment  of  a  multi-segment 
frame.  An  IPH  (time  stamp)  is  not  required  for  a  frame  segment  if  it  is  not  the  first 
segment  of  a  frame. 

0  =  Intra-Packet  Header  not  enabled 

1  =  Intra-Packet  Header  enabled 

•  Reserved.  Bits  26-0  are  reserved. 

b.  MJPEG  Video  Intra-Packet  Header.  After  the  CSDW,  the  format  3  MJPEG  video  data 
(complete  frame,  multiple  complete  frames,  or  frame  segment)  is  inserted  into  the  packet. 
The  frame  shall  be  preceded  by  an  IPH,  which  shall  provide  the  complete  frame  or  first 
frame  segment  time  stamp  and  the  frame  length.  The  IPH  time  stamp  value  indicates  the 
time  of  the  complete  frame  capture. 

The  IPH  consists  of  an  IPTS  and  intra-packet  data.  The  length  of  the  IPH  is  fixed  at  12 
bytes  (96  bits)  positioned  contiguously,  in  the  following  sequence  (Eigure  11-56). 

msb  Isb 

^1 _ 0_ 

TIME  (ESEW) _ 

TIME  (MSEW) _ 

ERAME  EENGTH _ 

Eigure  1 1-56.  MJPEG  Video  Intra-Packet  Header 
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•  Intra-Packet  Time  Stamp  (TIME).  These  8  bytes  indicate  the  time  tag  of  the  Format  3 
MJPEG  video  data.  First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate 
the  following  values: 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  MJPEG  frame  with 
bits  31  to  16  in  the  second  long  word  zero  filled  or; 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  MJPEG  frame. 

•  Intra-Packet  Data  (ERAME  EENGTH).  These  4  bytes  indicate  a  binary  value  that 
represents  the  byte  length  of  the  following  complete  frame. 


1 1 .2. 10.5  Video  Packets,  Eormat  4  (MJPEG-2000). 

Eormat  4  video  encoding  will  be  lAW  ISO/IEC  15444-3:2007  Motion  JPEG  2000.^"^  A 
set  of  images  for  this  type  with  compatible  parameters  can  be  placed  into  an  MJPEG-2000  video 
packet  as  shown  in  Table  11-39. 


Table  11-39.  MJPEG  Video  Packet,  Format  4 


msb  Isb 

15 _ 0 

_ PACKET  HEADER _ 

_ CHANNEE-SPECIEIC  DATA  (BITS  15-0) _ 

_ CHANNEE-SPECIEIC  DATA  (BITS  31-16) _ 

_ INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  15-0) _ 

_ INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  31-16) _ 

_ INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  47-32) _ 

_ INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  63-48) _ 

INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  79-64) 


INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  95-80) 


ERAME  BYTE  2 

ERAME  BYTE  1 

; 

; 

EIEEER  (IE  n  IS  ODD) 

ERAME  BYTE  n 

INTRA-PACKET  HEADER  EOR  SEGMENT  n  (BITS  15-0) 
INTRA-PACKET  HEADER  EOR  SEGMENT  n  (BITS  31-16) 
INTRA-PACKET  HEADER  EOR  SEGMENT  n  (BITS  47-32) 
INTRA-PACKET  HEADER  EOR  SEGMENT  n  (BITS  63-48) 
INTRA-PACKET  HEADER  EOR  SEGMENT  1  (BITS  79-64) 
INTRA-PACKET  HEADER  EOR  SEGMENT  n  (BITS  95-80) 


ERAME  BYTE  2 


ERAME  BYTE  1 


International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
technology:  JPEG  2000  image  coding  system:  motion  JPEG  2000.  ISO/IEC  15444-3:2007.  Geneva:  International 
Organization  for  Standardization,  2007. 


11-77 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


; 

; 

EIEEER  (IE  n  IS  ODD) 

ERAME  BYTE  n 

PACKET  TRAILER 

An  MJPEG-2000  video  packet  shall  contain  one  or  more  fixed-length  segments  of  a 
partial  MJPEG-2000  frame,  one  complete  MJPEG-2000  frame,  or  multiple  complete 
MJPEG-2000  frames. 

MJPEG-2000  video  packet  information  will  be  specified  in  the  CSDW. 


a.  MJPEG-2000  Video  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of 
each  MJPEG-2000  video  packet  begins  with  a  CSDW.  It  indicates  if  the  packet  body 
contains  several  complete  images  or  partial  images  (Eigure  11-57). 


msb 

Isb 

31  30 

29  28 

27 

26 

0 

PARTS 

SUM 

IPH 

RESERVED 

Eigure  1 1-57.  MJPEG  2000  Video  Packet  Channel-Specific  Data  Word 


•  Parts.  Bits  31-30  indicate  which  segment  of  the  frames  is  contained  in  the  packet  if 
the  packet  does  not  contain  one  or  more  complete  frames. 

00  =  Packet  does  not  contain  first  or  last  segment  of  frame 
01  =  Packet  contains  first  segment  of  frame 

10  =  Packet  contains  last  segment  of  frame 

11  =  Reserved 

•  Sum.  Bits  29-28  indicate  if  the  packet  contains  a  partial  frame  that  spans  multiple 
packets,  one  complete  frame,  or  multiple  complete  frames. 

00  =  Packet  contains  less  than  one  complete  frame  (a  segment) 

01  =  Packet  contains  one  complete  frame 

10  =  Packet  contains  multiple  complete  frame 

11  =  Reserved 

•  Intra-Packet  Header  (IPH).  Bit  27  indicates  that  the  IPH  (time  stamp/data)  shall 
precede  each  complete  frame  within  a  packet  or  the  first  segment  of  a  multi-segment 
frame.  An  IPH  (time  stamp)  is  not  required  for  a  frame  segment  if  it  is  not  the  first 
segment  of  a  frame. 

0  =  Intra-Packet  Header  not  enabled 

1  =  Intra-Packet  Header  enabled 

•  Reserved.  Bits  26-0  are  reserved. 

b.  MJPEG  Video  Intra-Packet  Header.  After  the  CSDW,  the  format  4  MJPEG-2000  video 
data  (complete  frame,  multiple  complete  frames,  or  frame  segment)  is  inserted  into  the 
packet.  The  frame  shall  be  preceded  by  an  IPH,  which  shall  provide  the  complete  frame 
or  first  frame  segment  time  stamp  and  the  frame  length.  The  IPH  time  stamp  value 
indicates  the  time  of  the  complete  frame  capture. 

The  IPH  consists  of  an  IPTS  and  intra-packet  data.  The  length  of  the  IPH  is  fixed  at  12 
bytes  (96  bits)  positioned  contiguously,  in  the  following  sequence  (Eigure  11-58). 
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msb 

_ 

TIME  (LSLW) 

TIME  (MSLW) 

ERAME  EENGTH 

Eigure  11-58.  MJPEG  Video  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp  (TIME).  These  8  bytes  indicate  the  time  tag  of  the  Eormat  4 
MJPEG-2000  video  data.  Eirst  long  word  bits  31-0  and  second  long  word  bits  31-0 
indicate  the  following  values: 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  MJPEG-2000 
frame  with  bits  31  to  16  in  the  second  long  word  zero  filled  or; 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  MJPEG-2000  frame. 

•  Intra-Packet  Data  (ERAME  EENGTH).  These  4  bytes  indicate  a  binary  value  that 
represents  the  byte  length  of  the  following  complete  frame. 

11.2.11  Image  Packets 

11.2.11.1  Image  Packets,  Eormat  0  (Image  Data) 

A  Eormat  0  image  packet  (Table  11-40)  shall  contain  one  or  more  fixed-length  segments 
of  one  or  more  video  images.  The  CSDW  for  an  image  packet  identifies  the  number  of  segments 
in  the  packet  and  the  portion  of  the  image  or  images  contained  in  the  packet.  If  the  optional  IPH 
is  not  included  with  each  segment,  the  RTC  in  the  packet  header  is  the  time  of  the  first  segment 
in  the  packet. 


Table  11-40.  Image  Packet,  Format  0 

msb 

Isb 

15 

0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

Optional  Intra-Packet  Header  for  Segment  1  (Bits  15-0) 

Optional  Intra-Packet  Header  for  Segment  1  (Bits  31-16) 

Optional  Intra-Packet  Header  for  Segment  1  (Bits  47-32) 

Optional  Intra-Packet  Header  for  Segment  1  (Bits  63-48) 

Byte  2 

Byte  1 

Tiller  (if  N  is  Odd) 

Byte  N 

Optional  Intra-Packet  Header  for  Segment  N  (Bits  15-0) 

Optional  Intra-Packet  Header  for  Segment  N  (Bits  31-16) 

Isb 

0 
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Optional  Intra-Packet  Header  for  Segment  N  (Bits  47-32) 

Optional  Intra-Packet  Header  for  Segment  N  (Bits  63-48) 

B3Te  2 

Byte  1 

Filler  (if  N  is  Odd) 

Byte  N 

Packet  Trailer 

a.  Image  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  image 
packet  begins  with  a  CSDW.  It  defines  the  byte  length  of  each  segment  and  indicates  if 
the  packet  body  contains  several  complete  images  or  partial  images,  and  whether  or  not 
the  IPDH  precedes  each  segment  (Figure  11-59). 


msb 

Isb 

31  30 

29  28 

27 

26 

0 

PARTS 

SUM 

IPH 

LENGTH 

Figure  1 1-59.  Image  Packet  Channel-Specific  Data  Word 


•  Parts.  Bits  31-30  indicate  which  piece  or  pieces  of  the  video  frame  are  contained  in 
the  packet. 

00  =  Packet  does  not  contain  first  or  last  segment  of  image 
01  =  Packet  contains  first  segment  of  image 

10  =  Packet  contains  last  segment  of  image 

11  =  Packet  contains  both  first  and  last  segment  of  image 

•  Sum.  Bits  29-28  indicate  if  the  packet  contains  a  partial  image,  one  complete  image, 
multiple  complete  images,  or  pieces  from  multiple  images. 

00  =  Packet  contains  less  than  one  complete  image 
01  =  Packet  contains  one  complete  image 
10  =  Packet  contains  multiple  complete  images 
11=  Packet  contains  multiple  incomplete  images 

•  Intra-Packet  Header  (IPH).  Bit  27  indicates  whether  the  IPH  (time  stamp)  precedes 
each  segment  of  the  image. 

0  =  The  IPH  not  enabled 
1  =  The  IPH  enabled 

•  Length.  Bits  26-0  indicate  a  binary  value  that  represents  the  byte  length  of  each 
segment. 

b.  Image  Intra-Packet  Header.  After  the  channel-specific  data.  Format  0  image  data  is 

inserted  into  the  packet.  Each  block  of  data  is  optionally  preceded  by  an  IPH  as  indicated 
by  the  IPH  bit  in  the  CSDW.  When  included,  the  IPH  consists  of  an  IPTS  only.  The 
length  of  the  IPH  is  fixed  at  8  bytes  (64  bits)  positioned  contiguously,  in  the  following 
sequence  (Figure  11-60). 
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Isb 
_0 

Time  (LSLW) _ 

Time  (MSLW) _ 

Figure  1 1-60.  Image  Data  Intra-Packet  Header,  Format  0 


msb 

31 


•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  Format  0  image 
data.  First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following 
values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  first  byte  with  bits 
31  to  16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  1 1.2. 1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  image  or  segment. 


11.2.11.2  Image  Packets,  Format  1  (Still  Imagery) 

A  Format  1  image  packet  (Table  11-41)  shall  contain  one  or  more  fixed-length  segments 
of  a  partial  still  image,  one  complete  still  image,  or  multiple  still  images.  The  still  image  source 
can  be  external  or  internal  to  the  recorder.  The  still  image  formats  will  be  specified  in  the 
CSDW  and  in  the  Computer- Generated  Data,  Format  1  setup  record  for  each  still  imagery 
channel.  Only  one  format  can  be  contained  within  each  channel  ID  for  still  imagery. 


Table  11-41.  Still  Imagery  Packet,  Format  1 

Isb 
_0 

Packet  Header 

_ Channel-Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Header  for  Segment  1  (Bits  15-0) 

Intra-Packet  Header  for  Segment  1  (Bits  31-16) 

Intra-Packet  Header  for  Segment  1  (Bits  47-32) 

Intra-Packet  Header  for  Segment  1  (Bits  63-48) 

Intra-Packet  Header  for  Segment  1  (Bits  79-64) 

Intra-Packet  Header  for  Segment  1  (Bits  95-80) 

Byte  2  Byte  1 


Filler  (if  N  is  Odd)  Byte  N 


Intra-Packet  Header  for  Segment  N  (Bits  15-0) 
Intra-Packet  Header  for  Segment  N  (Bits  31-16) 
Intra-Packet  Header  for  Segment  N  (Bits  47-32) 
Intra-Packet  Header  for  Segment  N  (Bits  63-48) 
Intra-Packet  Header  for  Segment  1  (Bits  79-64) 


msb 

15 
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Intra-Packet  Header  for  Segment  N  (Bits  95-80) 

B3Te  2 

Byte  1 

Eiller  (if  N  is  Odd) 

Byte  N 

Packet  Trailer 

a.  Still  Imagery  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  still 
image  packet  begins  with  a  CSDW.  It  defines  the  format  of  the  still  imagery  format 
(which  will  coincide  with  the  still  imagery  format  with  the  setup  record),  and  indicates  if 
the  packet  body  contains  several  complete  images  or  partial  images  (Figure  11-61). 
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Figure  11-61.  Still  Imagery  Packet  Channel- Specific  Data  Word 


•  Parts.  Bits  31-30  indicate  which  piece  or  pieces  of  the  image  are  contained  in  the 
packet. 

00  =  Packet  does  not  contain  first  or  last  segment  of  image 

01  =  Packet  contains  first  segment  of  image 

10  =  Packet  contains  last  segment  of  image 

11=  Packet  contains  both  first  and  last  segment  of  image 

•  Sum.  Bits  29-28  indicate  if  the  packet  contains  a  partial  image,  one  complete  image, 
multiple  complete  images,  or  pieces  from  multiple  images. 

00  =  Packet  contains  less  than  one  complete  image 
01  =  Packet  contains  one  complete  image 
10  =  Packet  contains  multiple  complete  images 
11=  Packet  contains  multiple  incomplete  images 

•  Intra-Packet  Header  (IPH).  Bit  27  indicates  whether  the  IPH  (time  stamp)  precedes 
each  segment  of  the  image. 

0=  The  IPH  not  enabled 
1=  The  IPH  enabled 

•  Format.  Bits  26-23  indicate  a  binary  value  that  represents  the  still  image  format. 

0000  =  MIL-STD-2500^^  National  Imagery  Transmission  Format 
0001  =  JPEG  File  Interchange  Format 
0010  =  JPEG  2000  (ISO/IEC  15444-1)26 


Department  of  Defense.  “National  Imagery  Transmission  Format  Version  2.1.”  MIL-STD-2500C.  May  2006. 
May  be  superseded  by  update.  Retrieved  27  April  2017.  Available  at 
http://quicksearch.dla.mil/qsDocDetails. ast)x?ident  number=l  12606. 

International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
Technology  —  JPEG  2000  Image  Coding  System:  Core  Coding  System.  ISO/IEC  15444-1:2016.  October  2016. 
May  be  superseded  by  update.  Retrieved  27  April  2017.  Available  for  purchase  at 
http://www.iso.org/iso/home/store/catalogue  tc/catalogue  detail.htm?csnumber=37674. 
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0011  =  Portable  Network  Graphics  Format 
0100-1111=  Reserved 

•  Reserved.  Bits  22-0  are  reserved. 

b.  Still  Imagery  Intra-Packet  Header.  After  the  channel- specific  data,  Format  1  still  imagery 
data  is  inserted  into  the  packet.  Each  still  image  or  segment  is  preceded  by  an  IPH.  The 
IPH  consists  of  an  IPTS  and  intra-packet  data.  The  length  of  the  IPH  is  fixed  at  12  bytes 
(96  bits)  positioned  contiguously,  in  the  following  sequence  (Figure  11-62). 


Figure  1 1-62.  Still  Imagery  Intra-Packet  Header 


•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  Format  1  still 
imagery  data.  First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the 
following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  still  image  or 
segment  with  bits  31  to  16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  still  image  or  segment. 

•  Intra-Packet  Data.  These  4  bytes  indicate  a  binary  value  that  represents  the  byte 
length  of  the  following  still  image  or  segment. 


1 1 .2. 1 1 .3  Image  Packets,  Format  2  (Dynamic  Imagery). 

A  Format  2  image  packet  (Table  11-42)  shall  contain  one  or  more  fixed-length  segments 
of  a  partial  dynamic  image,  one  complete  dynamic  image,  or  multiple  complete  dynamic  images. 
Typically  dynamic  image  packets  will  be  created  from  cameras  attached  to  a  recorder  or  cameras 
that  include  a  recording  capability. 

Table  11-42.  Dynamic  Imagery  Packet,  Format  1 

msb  Isb 

^5 _ 0_ 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) _ 

Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Header  for  Segment  1  (Bits  15-0) 

Intra-Packet  Header  for  Segment  1  (Bits  31-16) 

Intra-Packet  Header  for  Segment  1  (Bits  47-32) 

Intra-Packet  Header  for  Segment  1  (Bits  63-48) 
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Intra-Packet  Header  for  Segment  1  (Bits  79-64) 


Intra-Packet  Header  for  Segment  I  (Bits  95-80) 


Image  Byte  2 

Image  Byte  1 

Filler  (if  n  is  Odd) 

Image  Byte  N 

Intra-Packet  Header  for  Segment  N  (Bits  15-0) 
Intra-Packet  Header  for  Segment  N  (Bits  31-16) 
Intra-Packet  Header  for  Segment  N  (Bits  47-32) 
Intra-Packet  Header  for  Segment  N  (Bits  63-48) 
Intra-Packet  Header  for  Segment  I  (Bits  79-64) 


Intra-Packet  Header  for  Segment  N  (Bits  95-80) 


Image  Byte  2 

Image  Byte  1 

Filler  (if  n  is  Odd) 

Image  Byte  N 

Packet  Trailer 

Each  source  of  dynamic  imagery  (camera  or  sensor)  shall  have  its  own  individual  channel 
ID  value.  Multiple  sources  of  dynamic  imagery  (camera  or  sensor)  shall  not  share  the  same 
channel  ID  value.  Dynamic  Imagery,  Format  2  is  defined  as  image  data  that  has  a  rate  as 
opposed  to  Format  1  still  imagery,  which  does  not. 

Dynamic  image  information  will  be  specified  in  the  CSDW  and  in  the  Computer- 
Generated  Data,  Format  1  setup  record  for  each  dynamic  imagery  channel.  Only  one  dynamic 
imagery  format  can  be  defined  for  each  Format  2  image  packet  channel  ID. 

If  changes  are  made  to  the  initial  dynamic  imagery  channel  settings  in  the  Computer- 
Generated  Data,  Format  1  setup  record  a  new  setup  record  packet  shall  be  created  prior  to  any 
Format  2  image  packets  to  which  the  new  settings  are  applied.  These  changes  shall  be  noted  as  a 
setup  record  configuration  change  in  the  Computer-Generated  Data,  Format  1  setup  record 
CSDW. 

a.  Dynamic  Imagery  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each 
dynamic  image  packet  begins  with  a  CSDW.  It  defines  the  format  of  the  dynamic 
imagery  format  (which  will  coincide  with  the  dynamic  imagery  format  with  the  setup 
record)  and  indicates  if  the  packet  body  contains  several  complete  images  or  partial 
images  (Figure  11-63). 
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Figure  1 1-63.  Dynamic  Imagery  Packet  Channel-Specific  Data  Word 


•  Parts.  Bits  31-30  indicate  which  segment  of  the  image  is  contained  in  the  packet  if 
the  packet  does  not  contain  one  or  more  complete  images. 

00  =  Packet  does  not  contain  first  or  last  segment  of  image 
01  =  Packet  contains  first  segment  of  image 
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10  =  Packet  contains  last  segment  of  image 
11=  Reserved 

•  Sum.  Bits  29-28  indicate  if  the  packet  contains  a  partial  image  that  spans  multiple 
packets,  one  complete  image,  or  multiple  complete  images. 

00  =  Packet  contains  less  than  one  complete  image  (a  segment) 

01  =  Packet  contains  one  complete  image 

10  =  Packet  contains  multiple  complete  images 

11  =  Reserved 

•  Intra-Packet  Header  (IPH).  Bit  27  indicates  that  the  IPH  (time  stamp/data)  shall 
precede  each  complete  image  within  a  packet  or  the  first  segment  of  a  multi-segment 
image.  The  time  stamp  applied  to  each  complete  image  or  first  segment  of  an  image 
is  dependent  on  the  time  stamp  mode  as  defined  in  Subsection  1 1.2.1 1.3  item  b.  An 
IPH  (time  stamp)  is  not  required  for  an  image  segment  if  it  is  not  the  first  segment  of 
an  image. 

0=  The  IPH  is  not  enabled 
1=  The  IPH  is  enabled 

•  Format.  Bits  26-21  indicate  a  binary  value  that  represents  the  dynamic  image  pixel 
format  lAW  GenICam  Standard  Features  Naming  Convention  vl.5^’  or  later  and 
GigE  Vision  vl.2^*  or  later. 

0x00  =  Mono8 
0x01  =  Mono8Signed 
0x02  =  Mono  10 
0x03  =  MonolOPacked 
0x04  =  Mono  12 
0x05  =  Monol2Packed 
0x06  =  Monoid 
0x07  =  Mono  16 
0x08  =  BayerGR8 
0x09  =  BayerRG8 
0x0  A  =  BayerGB8 
OxOB  =  BayerBG8 
OxOC  =  BayerGRlO 
OxOD  =  BayerRGlO 
OxOE  =  BayerGBlO 
OxOE  =  BayerBGlO 
0x10  =  BayerGR12 
0x11=  BayerRG12 
0x12  =  BayerGB12 


European  Machine  Vision  Association.  GenICam  Standard  Features  Naming  Convention.  Version  1.5. 
November  201 1.  Retrieved  27  April  2017.  Available  at  httpV/www.emva.org/wp- 
content/uploads/GenlCam  SFNC  1  5.pdf. 

Automated  Imaging  Association.  GiCE  Vision.  Version  1.2.  n.d.  Retrieved  27  April  2017.  Available  for 
download  with  registration  at  http://www.visiononline.org/form.cfm7form  id=735. 
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0x13  =  BayerBG12 
0x14  =  BayerGRlOPacked 
0x15  =  BayerRGlOPacked 
0x16  =  BayerGBlOPacked 
0x17  =  BayerBGlOPacked 
0x18  =  BayerGR12Packed 
Ox  1 9  =  B  ayerRG  1 2Packed 
0x1  A  =  BayerGB12Packed 
Ox  1 B  =  B  ayerB  G 1 2Packed 
OxlC  =  BayerGR16 
OxlD  =  BayerRG16 
OxlE  =  BayerGB16 
OxlF  =  BayerBG16 
0x20  =  RGB8Packed 
0x21  =  BGR8Packed 
0x22  =  RGBA8Packed 
0x23  =  BGRA8Packed 
0x24  =  RGBlOPacked 
0x25  =  BGRlOPacked 
0x26  =  RGB12Packed 
0x27  =  BGR12Packed 
0x28  =  RGB16Packed 
0x29  =  BGR16Packed 
0x2A  =  RGBlOVlPacked 
0x2B  =  BGRlOVlPacked 
0x2C  =  RGB10V2Packed 
0x2D  =  BGR10V2Packed 
0x2E  =  RGB12VlPacked 
0x2E  =  RGB565Packed 
0x30  =  BGR565Packed 
0x31  =  YUV411Packed 
0x32  =  YUV422Packed 
0x33  =  YUV444Packed 
0x34  =  YUYVPacked 
0x35  =  RGB8Planar 
0x36  =  RGBlOPlanar 
0x37  =  RGB12Planar 
0x38  =  RGB16Planar 
0x39-0x3E  =  Reserved 
Ox3E  =  Device-specific 

•  Reserved.  Bits  20-0  are  reserved. 

b.  Dynamic  Imagery  Intra-Packet  Header.  After  the  CSDW,  the  Format  2  dynamic  imagery 
data  (complete  image,  multiple  complete  images,  or  image  segment)  is  inserted  into  the 
packet.  The  image  shall  be  preceded  by  an  IPH;  this  IPH  shall  provide  the  complete 
image  or  first  image  segment  time  stamp  and  the  image  length.  The  IPH  time  stamp 
value  indicates  the  time  of  the  complete  image  at  sensor/camera  capture. 
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The  image  time  stamp  characteristics  are  further  defined  within  the  setup  record  dynamic 
imagery  packet  channel  attributes.  Due  to  the  fact  that  dynamic  imagery  may  be  captured 
and  then  packetized  post-capture  there  maybe  uniqueness  in  regards  to  time  stamping  of 
the  data  versus  packet  header/secondary  header  values  related  to  the  first  bit  of  data 
within  the  packet  as  defined  in  sections  11.2.1.1  item  i  and  11.2.1.2  item  a.  Individual 
image  IPH  time  stamp  modes  are  defined  as  follows. 

(1)  Image  Capture  Time.  The  IPH  TIME  value  corresponds  to  the  RTC  or  absolute 
time  when  the  image  was  captured  by  the  sensor/camera.  The  packet  header 
RTC/packet  secondary  header  values  indicate  when  the  first  bit  of  data  is  placed 
into  the  packet.  When  Image  Capture  Time  mode  is  indicated  in  the  setup  record  it 
is  understood  there  is  a  delay  period  between  packet  header  RTC/secondary  header 
time  and  IPH  time. 

(2)  Image  Packetization  Time.  The  IPH  TIME  value  corresponds  to  the  RTC  or 
absolute  time  when  the  image  was  packetized.  The  packet  header  RTC/secondary 
header  values  indicate  when  the  first  bit  of  data  is  placed  into  the  packet.  Image 
packetization  time  is  defined  as  packetizing  image  data  as  it  is  captured  by  the 
sensor/camera.  When  Image  Packetization  Time  mode  is  indicated  in  the  setup 
record  it  is  understood  there  is  not  a  delay  period  between  packet  header 
RTC/secondary  header  time  and  the  image  IPH  time. 

The  IPH  consists  of  an  IPTS  and  intra-packet  data.  The  length  of  the  IPH  is  fixed  at  12 
bytes  (96  bits)  positioned  contiguously,  in  the  following  sequence  (Eigure  11-64). 


Eigure  11-64.  Dynamic  Imagery  Intra-Packet  Header 


•  Intra-Packet  Time  Stamp  (TIME).  These  8  bytes  indicate  the  time  tag  of  the  Eormat  2 
dynamic  imagery  data  as  defined  in  Section  II. 2. II. 3  item  b.  Eirst  long  word  bits  31- 
0  and  second  long  word  bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  dynamic  image 
with  bits  31  to  16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  dynamic  image. 

•  Intra-Packet  Data  (IMAGE  EENGTH).  These  4  bytes  indicate  a  binary  value  that 
represents  the  byte  length  of  following  complete  image. 
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11.2.12  UART  Data  Packets 

1 1 .2. 12. 1  UART  Data  Packets,  Format  0 

The  data  from  one  or  more  separate  asynchronous  serial  communieation  interfaee 
channels  (RS-232,  RS-422,  RS-485,  etc.)  can  be  placed  into  a  UART  data  packet  as  shown  in 
Table  11-43.  Note  that  9  bit  UART  data  is  not  supported  by  this  format. 


Table  11-43.  UART  Data  Packet  Format 

msb 

Isb 

15 

0 

Paeket  Header 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  1  (Bits  15-0) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  1  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  1  (Bits  47-32) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  1  (Bits  63-48) 

Intra-Packet  Data  Header  (UART  ID)  for  UART  1  (Bits  15-0) 

Intra-Packet  Data  Header  (UAR" 

r  ID)  for  UART  1  (Bits  31-16) 

Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  N 

(Optional)  Intra-Packet  Time  Stamp  for  UART  N  (Bits  15-0) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  N  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  N  (Bits  47-32) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  N  (Bits  63-48) 

Intra-Packet  Data  Header  (UART  ID)  for  UART  N  (Bits  15-0) 

Intra-Packet  Data  Header  (UAR" 

r  ID)  for  UART  N  (Bits  31-16) 

Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  N 

Paeket  Trailer 

a.  UART  Packet  Channel-Specifie  Data  Word.  The  packet  body  portion  of  eaeh  UART 
data  paeket  begins  with  a  CSDW  as  shown  in  Figure  11-65. 


msb 

Isb 

31 

30 

0 

IPH 

RESERVED 

Figure  1 1-65.  UART  Paeket  Channel-Specifie  Data  Word 


•  Intra-Packet  Header.  Bit  3 1  indicates  whether  the  IPH  time  stamp  is  inserted  before 
the  UART  ID  words. 

0  =  The  IPH  time  stamp  not  enabled 


11-88 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


1  =  The  IPH  time  stamp  enabled 
•  Reserved.  Bits  30-0  are  reserved. 

b.  UART  Intra-Packet  Header.  After  the  channel-specific  data,  UART  data  is  inserted  into 
the  packet.  Each  block  of  data  shall  be  preceded  by  an  IPH  with  optional  IPTS  and  a 
mandatory  UART  ID  word  IPDH.  The  length  of  the  IPH  is  either  4  bytes  (32  bits)  or  12 
bytes  (96  bits)  positioned  contiguously,  in  the  following  sequence  (Figure  11-66). 


Figure  1 1-66.  UART  Data  Intra-Packet  Header 


•  UART  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  UART 
data.  First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following 
values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  first  byte  with  bits 
31  to  16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  1 1.2. 1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  message. 

•  UART  Intra-Packet  Data  Header.  The  IPDH  is  a  UART  ID  word  that  precedes  the 
data  and  is  inserted  into  the  packet  with  the  following  format.  Inclusion  of  the  IPDH 
is  mandatory  and  is  not  controlled  by  the  IPH  bit  in  the  CSDW  (Figure  11-67). 


msb 

31 

30 

29 

16 

15 

Isb 

0 

PE 

RESERVED 

SUBCHANNEF 

DATA  FENGTH 

Figure  1 1-67.  Intra-Packet  Data  Header  Format 


o  Parity  Error  (PE).  Bit  3 1  indicates  a  parity  error. 

0  =  No  parity  error 
1  =  Parity  error 

o  Reserved.  Bit  30  is  reserved. 

o  Subchannel.  Bits  29-16  indicate  a  binary  value  defining  the  subchannel 
number  belonging  to  the  data  that  follows  the  UART  ID  word  when  the 
channel  ID  in  the  packet  header  defines  a  group  of  subchannels.  Zero  means 
first  and/or  only  subchannel  into  which  the  IPDH  is  inserted  before  the  UART 
ID  words. 

o  Data  Fength.  Bits  15-0  indicate  a  binary  value  representing  the  length  of  the 
UART  data  in  bytes  (n)  that  follows  the  UART  ID  word. 
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11.2.13  IEEE  1394  Data  Packets 

1 1 .2. 13. 1  IEEE  1394  Data  Packets,  Eormat  0(IEEE  1394  Transaction) 

This  format  applies  to  IEEE  1394  data  as  described  by  IEEE  1394-2008.^^  The  IEEE 
1394  data  is  packetized  to  encapsulate  completed  transactions  between  nodes.  A  packet  may 
contain  0  to  65,536  transactions,  but  is  constrained  by  the  common  packet  element  size  limits 
prescribed  in  Subsection  11.2.1.  The  IEEE  1394  packets  have  the  basic  structure  shown  in  Table 
11-44.  Note  that  the  width  of  the  structure  is  not  related  to  any  number  of  bits.  The  table  merely 
represents  relative  placement  of  data  within  the  packet. 

Table  11-44.  IEEE  1394  Data  Packet,  Format  0 

Packet  Header _ 

Channel-Specific  Data  Word 

(Optional)  Intra-Packet  Header 
(Optional)  Transaction  Data 
(Optional)  Intra-Packet  Header 
(Optional)  Transaction  Data 


(Optional)  Intra-Packet  Header 
(Optional)  Transaction  Data 
Packet  Trailer 


a.  IEEE  1394  Channel-Specific  Data  Word.  The  packet  body  portion  (Eigure  11-68)  of 
each  IEEE  1394  packet  shall  begin  with  a  CSDW. 
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SY 

RESERVED 

TC 

Eigure  1 1-68.  IEEE  1394  Channel-Specific  Data  Word 


•  Packet  body  Type  (PBT).  Bits  31-29  indicate  the  packet  body  type  as  follows: 

000  =  Type  0 
001  =  Type  1 
010  =  Type  2 
Oil-  111=  Reserved 

•  Synchronization  Code  (SY).  Bits  28-25  indicate  the  IEEE  1394  synchronization  code 
from  the  transaction.  This  field  is  mandatory  for  Type  1  packet  bodies.  Otherwise,  it 
is  reserved. 

•  Reserved.  Bits  24-16  are  reserved. 

•  Transaction  Count  (TC).  Bits  15-0  indicate  the  binary  value  of  the  number  of 
transactions  encapsulated  in  the  packet.  An  integral  number  of  complete  transactions 


Institute  of  Electrical  and  Electronics  Engineers.  IEEE  Standard  for  a  High-Performance  Serial  Bus.  IEEE  1394- 
2008.  New  York;  Institute  of  Electrical  and  Electronics  Engineers,  2008. 
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shall  be  included  in  each  packet.  It  is  mandatory  that  transaction  count  be  0  for  Type 
0  packet  bodies  and  1  for  Type  1  packet  bodies. 

b.  IEEE  1394  Intra-Packet  Header.  Each  IPH  shall  contain  an  8-byte  IPTS  only.  The 
format  of  an  IEEE  1394  IPH  is  described  by  Eigure  11-69. 

msb 

^1 _ 

Intra-Packet  Time  Stamp 

Intra-Packet  Time  Stamp 

Eigure  11-69.  IEEE  1394  Intra-Packet  Header 

•  IEEE  1394  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  IEEE 
1394  transaction  that  immediately  follows  it  in  the  packet.  Time  is  coded  lAW  all 
other  Chapter  1 1  packet  formats.  Specifically,  the  first  long  word  bits  31-0  and 
second  long  word  bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  of  the  transaction,  with 
bits  31-16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  of  the  transaction. 

c.  IEEE  1394  Data  Packet  Body  Types.  Three  packet  body  types  are  defined  for  the 
encapsulation  of  IEEE  1394  data.  Regardless  of  type,  each  packet  body  shall  begin  with 
the  IEEE  1394  packet  CSDW  as  described  by  Subsection  11.2.13.1  item  a  above.  The 
packet  body  type  is  indicated  within  the  CSDW.  Depending  on  the  packet  body  type,  the 
CSDW  is  followed  by  0  or  more  transactions.  In  addition,  dependent  on  packet  body 
type,  each  transaction  may  be  preceded  by  an  IPH. 

•  IEEE  1394  Packet  Body  Type  0:  Bus  Status.  Type  0  packet  bodies  shall  contain  zero 
IPHs  and  zero  transactions.  The  CSDW  transaction  count  shall  be  zero.  The  packet 
body  shall  contain  the  CSDW  immediately  followed  by  a  single  32-bit  word. 

Bus  status  events  shall  be  encapsulated  by  Type  0  packet  bodies.  The  32-bit  word  in 
the  packet  body  shall  contain  an  event  data  word  as  indicated  in  Eigure  11-70. 
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Eigure  1 1-70.  IEEE  1394  Event  Data  Word 


o  RESET  (RE).  Bit  31,  when  set,  indicates  that  an  IEEE  1394  bus  reset  has 
occurred. 

o  RESERVED.  Bits  30-0  are  reserved. 

•  IEEE  1394  Packet  Body  Type  1:  Data  streaming.  Type  1  packet  bodies  shall 

encapsulate  IEEE  1394  data  streaming  only.  Type  1  packet  body  data  is  restricted  to 
that  from  an  IEEE  1394  packet  with  a  transaction  code  of  Ox  A,  be  it  from  an 


Isb 

0 
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isochronous  channel  or  asynchronous  stream.  The  packet  body  shall  contain  zero 
IPHs  and  one  transaction.  The  CSDW  transaction  count  shall  be  one. 

The  CSDW  is  immediately  followed  by  a  non-zero  number  of  data  bytes.  The  data 
bytes  shall  be  exactly  those  of  a  single  IEEE  1394  data  block,  excluding  the  IEEE 
1394  packet  header  and  data  block  CRC.  Data  recorded  from  the  stream  shall  be 
known  to  be  valid,  insofar  as  both  the  IEEE  1394  header  CRC  and  data  block  CRC 
tests  have  passed.  The  number  of  data  bytes  shall  be  exactly  four  less  than  the  value 
indicated  in  data  length  lAW  the  definition  of  packet  header  data  length  and 
accounting  for  the  size  of  the  CSDW.  Conversely,  the  value  stored  in  the  packet 
header  data  length  shall  be  the  number  of  bytes  in  the  IEEE  1394  data  block  plus 
four.  The  synchronization  code  (SY)  from  the  stream  packet  shall  be  indicated  in  the 
CSDW,  and  the  channel  number  shall  be  indicated  in  the  packet  header  channel  ID. 

•  IEEE  1394  Packet  Body  Type  2:  General-Purpose.  Type  2  packet  bodies  encapsulate 
complete  IEEE  1394  packets,  including  header  and  data.  Use  of  Type  2  packet 
bodies  is  unrestricted  and  may  encapsulate  streaming,  non-streaming  (IEEE  1394 
packets  with  transaction  codes  other  than  OxA),  isochronous,  and  asynchronous  data. 
Multiple  IEEE  1394  packets,  with  differing  transaction  codes  and  channel  numbers, 
may  be  carried  within  a  single  Type  2  packet  body. 

The  CSDW  shall  be  followed  by  a  non-zero  number  of  completed  transactions  as 
indicated  by  the  CSDW  transaction  count.  Each  transaction  shall  be  preceded  by  an 
IPH  as  defined  above  for  IEEE  1394  data  packets.  Immediately  following  the  IPH, 
the  transaction  shall  be  recorded  in  its  entirety  and  must  be  a  properly  formed  IEEE 
1394  packet  lAW  the  specification  in  use.  The  revision  of  the  specification  used  shall 
be  declared  within  the  accompanying  setup  record  packet. 


All  IEEE  1394  packets  contain  a  4-bit  Transaction 
Code  field  (tcode).  This  field  indicates  the  IEEE 
1394  specific  format  of  the  transaction. 


NOTE 


11.2.13.2  IEEE  1394  Data  Packets,  Eormat  I  (IEEE  1394  Physical  Eayer). 

This  format  applies  to  IEEE  1394  data  as  described  by  IEEE  1394-1995,  IEEE  1394a, 
and  IEEE  1394b.  The  IEEE  1394  data  is  packetized  in  Eormat  I  packets  as  physical  layer  data 
transfers  (lAW  Annex  J  of  Standard  1394-1995^°  and  Chapter  17  of  Standard  1394b-2002^*).  A 
packet  may  contain  0  to  65,536  transfers,  but  is  constrained  by  the  common  packet  element  size 
limits  prescribed  in  Subsection  11.2.1.  The  IEEE  1394  packets  have  the  basic  structure  shown  in 
Table  11-45  below.  Note  that  the  width  of  the  structure  is  not  related  to  any  number  of  bits.  The 
drawing  merely  represents  relative  placement  of  data  within  the  packet. 


Institute  of  Electrical  and  Electronics  Engineers.  IEEE  Standard  for  a  High  Performance  Serial  Bus.  IEEE  1394- 
1995.  New  York:  Institute  of  Electrical  and  Electronics  Engineers,  1995. 

Institute  of  Electrical  and  Electronics  Engineers.  IEEE  Standard  for  a  High  Performance  Serial  Bus:  Amendment 
2.  IEEE  13946-2002.  New  York:  Institute  of  Electrical  and  Electronics  Engineers,  2002. 
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Table  11-45.  IEEE  1394  Data  Packet,  Format  1 

Packet  Header _ 

Channel-Speeific  Data  Word _ 

Intra-Packet  Header 

Data _ 

(Optional)  Intra-Paeket  Header 
(Optional)  Data 


(Optional)  Intra-Packet  Header 
(Optional)  Data _ 

Paeket  Trailer 


a.  IEEE  1394  Channel-Specific  Data  Word.  The  packet  body  portion  (Eigure  11-71)  of 
each  IEEE  1394  packet  shall  begin  with  a  CSDW. 


msb 

Isb 

31 

16 

15 

0 

RESERVED 

IPC 

Eigure  11-71.  IEEE  1394  Channel- Speeifie  Data  Word,  Eormat  1 


•  Reserved.  Bits  31-16  are  reserved. 

•  Intra-Paeket  Count  (IPC).  Bits  15-0  indicate  the  binary  value  of  the  number  of  intra- 
paekets  eneapsulated  in  the  Chapter  1 1  paeket.  An  integral  number  of  eomplete  intra¬ 
packets  shall  be  included  in  each  Chapter  1 1  packet. 

b.  IEEE  1394  Eormat  1  Intra-Paeket  Header.  The  CSDW  is  followed  by  1  or  more  IEEE 
1394  transfers.  Eaeh  transfer  starts  with  an  IPH,  followed  by  0-32,780  eneapsulated  data 
bytes.  The  length  of  the  IPH  is  fixed  at  12  bytes  (96  bits)  positioned  contiguously,  in  the 
following  sequenee  as  shown  in  Eigure  11-72. 

msb 

^1 _ 

Intra-Packet  Time  Stamp 
Intra-Paeket  Time  Stamp 
Intra-Paeket  ID  Word 

Eigure  11-72.  IEEE  1394  Eormat  1  Intra-Packet  Header 

•  IEEE  1394  Eormat  1  Intra-Paeket  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of 
the  IEEE  1394  transfer  that  immediately  follows  it  in  the  paeket.  Time  is  eoded  lAW 
all  other  Chapter  1 1  paeket  formats.  Specifically,  the  first  long  word  bits  31-0  and 
second  long  word  bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  byte  of  the  transfer,  with  bits 
15-0  in  the  seeond  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indieated  by  bits  2  and  3  in  the  packet  flags 


Isb 

0 
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(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
byte  of  the  transfer. 


•  Message  ID  Word.  These  4  bytes  are  an  ID  word  that  precedes  the  message  and  is 
inserted  into  the  packet  as  in  Figure  11-73. 


msb 

31  24 

23  20 

19  18 

17 

16 

15 

Isb 

0 

STATUS  BYTE 

SPEED 

TREOVE 

EBO 

RSV 

DATA  EENGTH 

Figure  1 1-73.  Intra-Packet  Data  Header  -  Message  ID  Word 


o  Status  Byte.  Bits  31-24  define  the  status  byte  received  from  the  physical  layer 
devices  lAW  IEEE  1394b  specification. 

o  Transmission  Speed  (SPEED).  Bits  23-20  identify  the  speed  of  transmission 
of  the  message.  (Speed  codes  lAW  IEEE  1394b) 

0000  =  S  100  A 

0001  =  S  100  B 

0010  =  S200  A 

0011  =  S200B 

0100  =  S400  A 

0101  =  S400  B 

0111  =  S800B 

1001  =  S1600B 

1010  =  S3200B 

Other  values  are  reserved 

o  Transfer  Overflow  Error  (TREOVE).  Bits  19-18  indicate  if  a  transfer 
synchronization  error  occurred. 

00  =  IEEE  1394  flow  did  not  exceed  maximum  intra-packet  size. 

01  =  This  IEEE  1394  transfer  started  correctly  but  longer  than  the  standard 
transfer  length. 

10  =  The  previous  IEEE  1394  transfer  was  in  01 -type  overflow  and  this 
IEEE  1394  transfer  ended  correctly  (did  not  exceed  standard  transfer 
length). 

11=  The  previous  IEEE  1394  transfer  was  in  01 -type  overflow  and  this 
IEEE  1394  transfer  did  not  end  correctly  (exceeds  standard  transfer 
length). 

Most  of  the  time,  this  field  shall  be  00.  Possible  combinations  are:  01  intra¬ 
packet,  zero  or  more;  11  intra-packet;  and  finally  10  intra-packet. 

o  Eocal  Buffer  Overflow  (EBP).  Bit  17,  if  set,  indicates  that  some  messages  are 
lost  before  this  transfer  due  to  local  buffer  overflow. 

o  Reserved  (RSV).  Bit  16  is  reserved. 

o  Data  Eength.  Bits  15-0  contain  a  binary  value  that  represents  the  length  of  the 
transfer  in  bytes  (n)  that  follows  the  ID  word.  The  maximum  length  of  a 
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captured  data  is  4120  for  transfers  corresponding  to  asynchronous  packets  and 
32,780  for  transfers  corresponding  to  isochronous  packets. 

If  the  data  length  field  is  not  a  multiple  of  4  bytes,  1-3  fill  bytes  of  0x00  are 
added  to  maintain  the  packet  structures  in  32-bit  boundary. 

If  the  data  length  field  contains  0,  the  intra-packet  data  is  not  provided  and 
this  word  contains  only  the  status  byte  information. 

c.  IEEE  1394  Format  1  Packet  Body.  The  packet  body  shall  encapsulate  IEEE  1394 
isochronous  or  asynchronous  message  data.  The  data  b3Tes  shall  be  exactly  those  of  a 
single  IEEE  1394  physical  transmission  message,  including  the  IEEE  1394  packet  header 
and  data  block  CRC.  The  data  length  field  shall  indicate  the  exact  number  of  total  bytes 
encapsulated  in  the  message  data. 

11.2.14  Parallel  Data  Packet 

11.2.14.1  Format  0 

Parallel  data  packets  are  designed  to  record  data  from  parallel  interfaces  (2-128  bit  wide) 
including  the  industry  de  facto  standard  8-bit  Digital  Cartridge  Recording  System  -  Incremental 
(DCRsi)  interface.  A  single  packet  can  hold  data  words  or  special  data  structures  as  currently 
defined  for  the  DCRsi  scan  format.  The  exact  format  selection  is  defined  in  the  CSDW.  The 
data  recorded  from  a  parallel  interface  shall  be  placed  into  a  Parallel  Data  Packet,  Format  0  as 
shown  in  Table  11-46. 


a.  Parallel  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  parallel 
data  packet  begins  with  a  CSDW.  The  CSDW  is  formatted  as  shown  in  Figure  11-74. 


msb 

31 

24 

23 

Isb 

0 

TYPE 

RESERVED  (0)  OR  SCAN  NUMBER 

Figure  11-74. 

Parallel  Packet  Channel-Specific  Data  Word 

•  Type.  Bits  31-24  indicate  the  data  type  stored. 

0x01  -  0x00:  Reserved 

0x80  -  0x10:  Number  of  bits  of  recorded  data  (parallel  data  word  width  in  bits) 
OxFD  -  0x8 1 :  Reserved 
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OxFE:  DCRsi  scan  format,  contains  auxiliary  data,  DCRsi  main  data 
OxFF:  Reserved 

•  Sean  Number.  Bits  23-0  are  reserved  (0)  for  general-purpose  parallel  data  packets  or 
eontain  the  sean  number  of  the  first  sean  stored  in  the  paeket  for  DCRsi  data. 

b.  General-Purpose  Parallel  Data.  General-purpose  parallel  data  paekets  ean  eontain  any 
number  of  data  bytes,  as  indieated  in  the  data  length  field  in  the  paeket  headers  (Figure 
11-75). 


msb  Isb 

15  0 

Pad 

Data  Word  2 

Pad 

Data  Word  1 

Pad 

Data  Word  n,  or  Pad  if  Fength  is  Odd 

Pad 

Data  Word  N-1 

Figure  11-75.  Parallel  Data,  Up  to  8 -Bit-Wide  Words 


NOTE 


To  get  the  number  of  data  words  stored  in  the  paeket, 
the  data  length  must  be  divided  by  the  number  of 
bytes  neeessary  to  hold  one  parallel  data  word. 


•  If  the  number  of  data  bits  is  8  or  less,  the  word  shall  be  padded  with  zeros  to  8-bit 
bytes. 

•  If  the  number  of  data  bits  is  between  9  and  16,  the  words  shall  be  padded  with  zeros 
to  one  16-bit  word,  as  in  Figure  11-76. 


msb 

Isb 

15 

0 

Pad 

Data  Word  1 

Pad 

Data  Word  N 

Figure  1 1-76.  Parallel  Data,  9-Bit  to  16-Bit-Wide  Words 


•  If  the  number  of  data  bits  is  greater  than  16,  the  words  shall  be  padded  with  zeros  to 
multiples  of  16-bit  data  words.  Figure  11-77  shows  storing  of  28-bit  data  words. 


msb 

15 

Isb 

0 

Data  Word  1,  Isbs  15-0 

Pad 

Data  Word  1,  msbs  27-16 

Data  Word  N,  Isbs  15-0 

Pad 

Data  Word  N,  msbs  27-16 

Figure  1 1-77.  Parallel  Data  (Example:  28-Bit-Wide  Words) 


e.  DCRsi  Parallel  Data  Paekets.  The  DCRsi  data  paekets  ean  eontain  any  number  of 
complete  DCRsi  scans,  containing  9  auxiliary  data  and  4356  main  data  bytes.  The 


11-96 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


number  of  the  scans  can  be  calculated  from  the  data  length  field  of  the  packet  header. 
The  structure  of  one  DCRsi  scan  is  in  Figure  11-78. 


msb  Isb 

15  0 

Auxiliary  Data  2 

Auxiliary  Data  1 

Pad  (0) 

Auxiliary  Data  3 

Auxiliary  Data  5 

Auxiliary  Data  4 

Pad  (0) 

Auxiliary  Data  6 

Auxiliary  Data  8 

Auxiliary  Data  7 

Pad  (0) 

Auxiliary  Data  9 

Data  Byte  2 

Data  Byte  1 

Data  Byte  4 

Data  Byte  3 

Data  Byte  4356 

Data  Byte  4355 

Figure  11-78.  DCRsi  Scan,  9- Auxiliary  Data  Byte  -i-  4326  Bytes 


The  length  of  the  packet  can  be  only  N  *  (12  -i-  4356)  -i-  4  bytes,  including  the  length  of 
the  CSDW. 

Any  DCRsi  data  without  auxiliary  data  bytes  can  be  stored  also  as  8 -bit  general-purpose 
parallel  data  as  described  in  Subsection  11.2.14  item  b. 

11.2.15  Ethernet  Data  Packets 


1 1 .2. 15. 1  Ethernet  Data  Packets,  Eormat  0 

Data  from  one  or  more  Ethernet  network  interfaces  can  be  placed  into  an  Ethernet  Data 
Packet  Eormat  0  as  shown  in  Table  11-47. 


Table  11-47.  Ethernet  Data  Packet,  Format  0 

msb  Isb 

25 _ 0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) _ 

Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  15-0) 

Intra-Packet  Time  Stamp  for  Msg  I  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Msg  I  (Bits  47-32) 

Intra-Packet  Time  Stamp  for  Msg  I  (Bits  63-48) 

Intra-Packet  Data  Header  for  Msg  I  (Bits  15-0) 


Intra-Packet  Data  Header 

brMsg  I  (Bits  31-16) 

Byte  2 

Byte  I 

Eiller  (if  n  is  Odd) 

Byte  n 

Intra-Packet  Time  Stamp  for  Msg  n  (Bits  15-0) 
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Intra-Packet  Time  Stamp  for  Msg  n  (Bits  31-16) 
Intra-Packet  Time  Stamp  for  Msg  n  (Bits  47-32) 
Intra-Packet  Time  Stamp  for  Msg  n  (Bits  63-48) 


Intra-Packet  Data  Header  for  Msg  n  (Bits  15-0) 


Intra-Packet  Data  Header 

br  Msg  n  (Bits  31-16) 

Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  n 

Packet  Trailer 

a.  Ethernet  Data  Packet  Format  0,  Channel-Specific  Data  Word.  The  packet  body  portion 
of  each  Ethernet  data  packet  begins  with  a  CSDW.  It  indicates  the  format  of  the  Ethernet 
data  packet  contents,  applicable  TTBs,  and  how  many  media  access  control  (MAC) 
frames  are  placed  in  the  packet  body.  The  CSDW  is  formatted  for  the  complete  type  of 
packet  body  as  shown  in  Figure  11-79. 
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31  28 

27  25 

24 

16 

15 

Isb 

0 

FORMAT 

TTB 

RESERVED 

NUMBER  OF  FRAMES 

Figure  1 1-79.  Ethernet  Data  Packet  Format  0  Channel-Specific  Data  Word 


•  Format.  Bits  31-28  indicate  the  type  of  Ethernet  packet. 

0000  =  Ethernet  physical  layer  IEEE  802.3  MAC  Frame 
000 1-1111  =  Reserved 

•  Time  Tag  Bits  (TTB).  Bits  27-25  indicate  which  bit  of  the  Ethernet  MAC  frame  the 
IPH  time  tag  is  applicable  to. 

000  =  First  bit  of  the  MAC  frame  MAC  destination  address 

001  =  East  bit  of  the  MAC  frame  check  sequence 

010  =  First  bit  of  the  MAC  frame  payload  data 

011  =  East  bit  of  the  MAC  frame  payload  data 

100-11 1  =  Reserved 

•  Reserved.  Bits  24-16  are  reserved. 

•  Number  of  Frames.  Bits  15-0  contain  a  binary  value  that  represents  the  number  of 
frames  included  in  the  packet. 

b.  Ethernet  Data  Packet  Format  0,  Intra-Packet  Header.  After  the  channel-specific  data, 
Ethernet  data  is  inserted  into  the  packet.  Each  frame  is  preceded  by  an  IPH  that  has  both 
an  IPTS  and  an  IPDH  containing  a  frame  ID  word.  The  length  of  the  IPH  is  fixed  at  12 
bytes  (96  bits)  positioned  contiguously,  in  the  following  sequence  as  shown  in  Figure 
11-80. 
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Figure  1 1-80.  Ethernet  Data  Format  0  Intra-Packet  Header 


•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  frame  data.  First 
long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  TTBs  in  the  CSDW  of  the  frame  with 
bits  31  to  16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  data  bit 
indicated  in  the  TTBs  in  the  CSDW  of  the  frame. 


•  Frame  ID  Word.  The  frame  ID  word  is  an  identification  word  that  precedes  the 
Ethernet  frame  and  is  inserted  into  the  packet  with  the  format  shown  in  Figure  11-81. 
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ECE 

EE 

CONTENT 

SPEED 

NETID 

DCE 

EE 

DATA  EENGTH 

Figure  11-81.  Intra-Packet  Frame  ID  Word 


o  Frame  CRC  Error  (FCE).  Bit  31,  the  frame  CRC  error  bit,  is  used  to  indicate 
that  a  MAC  frame  CRC  error  occurred  during  frame  transmission. 

0  =  No  frame  CRC  error 
1  =  Erame  CRC  error  encountered 

o  Erame  Error  (EE).  Bit  30,  the  frame  error  bit,  is  used  to  indicate  any  error  that 
occurred  during  frame  transmission. 

0  =  No  frame  error 
1  =  Erame  error  encountered 

o  Captured  Data  Content  (CONTENT).  Bits  29-28  specify  the  extent  of  the 
captured  MAC  frame. 

00  =  Eull  MAC  frame:  starting  with  the  6-byte  destination  MAC  address 
and  ending  with  the  4-byte  frame  check  sequence. 

01  =  Payload  (data)  only:  starting  at  the  14*  byte  offset  from  the 

beginning  of  the  destination  MAC  address  and  ending  before  the  4- 
byte  frame  check  sequence  of  the  MAC  frame. 

10  =  Reserved  for  future  format. 

11=  Reserved  for  future  format. 

o  Ethernet  Speed  (SPEED).  Bits  27-24  indicate  the  negotiated  bit  rate  for  the 
identified  NETID  on  which  the  frame  was  captured. 

0000  =  Auto 
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0001  =  10  megabits  per  second  (Mbps) 

0010  =  100  Mbps 

0011  =  1  gigabit  per  second  (Gbps) 

0100  =  10  Gbps 
0101  -1111  =  Reserved 

o  Network  Identifier  (NETID).  Bits  23-16  contain  a  binary  value  that  represents 
the  physical  network  identification  of  frame  origination  that  follows  the  ID 
word.  Zero  means  first  and/or  only  physical  network. 

o  Data  CRC  Error  (DCE).  Bit  15,  the  data  CRC  error  bit,  is  used  to  indicate  that 
a  CRC  error  exists  in  the  payload  of  the  frame. 

0  =  No  data  CRC  error 
1  =  Data  CRC  error  encountered 

o  Data  Length  Error  (LE).  Bit  14,  the  data  length  error  bit,  is  used  to  indicate 
that  the  frame  is  too  short  (less  than  64  bytes)  or  too  long  (longer  than  1518 
bytes). 

0  =  Valid  length 

1  =  Data  length  ID  too  short  or  too  long. 

o  Data  Length.  Bits  13-0  contain  a  binary  value  that  represents  the  length  of  the 
frame  in  bytes  (n)  that  follows  the  ID  word. 

11.2.15.2  Ethernet  Data  Packets,  Format  1,  ARINC-664 

Any  User  Datagram  Protocol  (UDP)  packets  from  Ethernet  and/or  ARINC-664  Part  7 
(referred  to  as  “ARINC-664”  in  this  standard)  network  interfaces  can  be  placed  into  an  Ethernet 
Data  Packet  Format  1  as  shown  in  Table  11-48. 


Table  11-48.  Ethernet  Data  Format  1 

msb  Isb 

15  0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  15-0) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  47-32) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  63-48) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  15-0) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  31-16) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  47-32) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  63-48) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  79-64) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  95-80) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  1 1 1-96) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  127-112) 
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Byte  2 

Byte  1 

Eiller  (if  n  is  Odd) 

Byte  N 

Intra-Packet  Time  Stamp  for  Msg  N  (Bits  15-0) 
Intra-Packet  Time  Stamp  for  Msg  N  (Bits  31-16) 
Intra-Packet  Time  Stamp  for  Msg  N  (Bits  47-32) 
Intra-Packet  Time  Stamp  for  Msg  N  (Bits  63-48) 
Intra-Packet  Data  Header  for  Msg  N  (Bits  15-0) 


Intra-Packet  Data  Header  for  Msg  N  (Bits  127-112) 


Byte  2 

Byte  1 

Eiller  (if  n  is  Odd) 

Byte  N 

Packet  Trailer 

The  ARINC-664  is  based  on  the  Ethernet  specification,  IEEE  Standard  802.3-2012.^^ 
Unlike  the  Ethernet  frame,  the  last  byte  of  a  frame  payload  is  used  for  the  frame  sequence 
number.  This  byte  is  located  just  before  the  MAC  CRC  field,  as  part  of  the  MAC  payload. 
Ethernet  Data  Packets,  Eormat  1  ARINC-664  shall  capture  and  store  the  entire  ARINC-664 
message  (the  entire  UDP  payload),  including  one  or  more  fragmented  frames. 

The  ARINC-664  frame  sequence  numbers  are  used  by  the  end  system  for  integrity 
checking  and  redundancy  management.  ARINC-664  requires  two  redundant  switch  networks. 
Each  ARINC-664  frame  is  replicated  and  sent  on  both  networks.  The  ARINC-664  receiving  end 
system  uses  the  sequence  number  to  check  for  dropped  frames  and  to  eliminate  redundant 
frames.  The  link  layer  of  the  receiver’s  ARINC-664  interface  discards  the  sequence  number  and 
drops  the  redundant  frame  before  passing  the  frame’s  payload  to  the  Internet  Protocol  (IP) 
network  layer  of  the  protocol  stack.  If  a  UDP  datagram  is  fragmented,  the  sequence  numbers  on 
the  fragments  are  discarded  prior  to  datagram  reassembly.  Table  11-49  compares  a  normal 
Ethernet  frame  with  an  ARINC-664  frame. 


Table  11-49.  Comparison  of  Normal  Ethernet  and  ARINC-664  Frames 

Normal  Ethernet 

i’rame 

7  bytes 

1  byte 

14  bytes 

20  bytes 

8  bytes 

<  1472 
bytes 

4  bytes 

Preamble 

Start 

Delimiter 

MAC 

Header 

IP  Header 

UDP 

Header 

UDP 

Payload 

PCS 

ARINC-664  Frame 

7  bytes 

1  byte  Mbytes  20  bytes  8  bytes  <1471  1  byte  4 bytes 

bytes 

Institute  of  Electrical  and  Electronics  Engineers.  IEEE  Standard  for  Ethernet.  IEEE  802.3-2012.  New  York; 
Institute  of  Electrical  and  Electronics  Engineers. 
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Preamble 

Start 

MAC 

IP 

UDP 

ARINC- 

Sequence 

FCS 

Delimiter 

Header 

Header 

Header 

664 

Payload 

Number 

a.  Ethernet  Data  Format  1,  Channel-Specific  Data  Word.  The  packet  body  portion  of  each 
Ethernet  data  packet  begins  with  a  CSDW.  It  indicates  how  many  ARINC-664  messages 
are  placed  in  the  packet  body.  The  CSDW  is  formatted  for  the  complete  type  of  packet 
body  as  shown  in  Figure  11-82. 
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Figure  1 1-82.  Ethernet  Data  Packet  Format  1  Channel- Specific  Data  Word 


•  Intra-Packet  Header  Fength.  Bits  31-16  contain  the  length  of  the  IPH  in  bytes;  this  is 
fixed  at  28. 

•  Number  of  Messages.  Bits  15-0  contain  a  binary  value  that  represents  the  number  of 
messages  included  in  the  packet. 

b.  Ethernet  Data  Packet  Format  1  Intra-Packet  Header.  After  the  channel- specific  data, 
ARINC-664  data  is  inserted  into  the  packet.  Each  message  is  preceded  by  an  IPH  that 
has  both  an  IPTS  and  an  IPDH.  The  length  of  the  IPH  is  fixed  at  28  bytes  (224  bits) 
positioned  contiguously,  in  the  following  sequence  as  shown  in  Figure  11-83. 

msb  Isb 

^1 _ 0_ 

Time  (FSFW) _ 

Time  (MSFW) _ 

Intra-Packet  Data  Header  1 
Intra-Packet  Data  Header  2 
Intra-Packet  Data  Header  3 
Intra-Packet  Data  Header  4 
Intra-Packet  Data  Header  5 

Figure  1 1-83.  Ethernet  Data  Format  1  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  ARINC-664 
message.  First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the 
following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  frame  with  bits  31 
to  16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  frame. 
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•  Intra-Packet  Data  Header.  These  20  bytes  contain  ARINC-664  message  data  length, 
virtual  link,  source  and  destination  IP  addresses,  and  source  and  destination  UDP 
ports,  as  shown  in  Figure  11-84. 
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Figure  1 1-84.  Intra-Packet  Data  Header 


o  Data  Length  (bits  31-16) 

Message  length  in  bytes 

o  ERROR  Bits  (bits  15-8) 

0:  No  errors 
1 :  Any  undefined  error 
2-15:  Reserved 

o  Flags  (bits  7-0) 

0:  Actual  ARINC-664  data 
1 :  Simulation  ARINC-664  data 
2-15:  Reserved 

o  Reserved  (bits  31-16) 

o  Virtual  Link  (VL)  (bits  15-0) 

Lower  16  bits  of  the  Ethernet  destination  MAC  address 

o  Source  IP  address  (bits  31-0) 

Source  IP  address  from  ARINC-664  IP  header 

o  Pest  IP  Address  (bits  31-0) 

Destination  IP  address  from  ARINC-664  IP  header 

o  Src  Port  (bits  31-16) 

16  bits  source  port  from  the  ARINC-664  UDP  header 
o  Pest  Port  (bits  15-0) 

Destination  port  from  the  ARINC-664  UDP  header 

11.2.16  Time  Space  Position  Information  and  Combat  Training  Systems  Data  Packets 

The  Time  Space  Position  Information  (TSPI)  and  Combat  Training  Systems  (CTS)  data 
type  packets  are  provided  to  allow  a  defined  method  of  TSPLCTS  data  encapsulation  in  Chapter 
1 1  packet  format.  This  will  provide  interoperability  of  these  data  sets  between  ranges  and  users 
along  with  alignment  to  other  digital  data  in  the  recording,  such  as  video  and  audio. 


11-103 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


The  TSPI/CTS  data  packets  do  not  require  a  specific  input  interface  such  as  PCM, 
analog,  or  MIL-STD-1553.  The  TSPI/CTS  data  type  will  only  encapsulate  multiple  types  of 
TSPI/CTS  information  lAW  governing  standards  and  specifications.  Essentially,  TSPECTS  data 
will  be  wrapped  in  its  native  format  by  Chapter  1 1  packet  structures  and  reside  on  compliant 
media  devices  and/or  within  files.  The  packet  definition  will  not  characterize  transmission 
protocols  or  requirements  because  those  are  provided  by  the  governing  standards  or 
specifications. 

The  TSPECTS  packets  are  considered  dynamic  and  timing  requirements  (e.g.,  of  Chapter 
10)  apply  whether  they  are  generated  by  the  recorder/multiplexer,  like  computer-generated  data 
packets,  or  generated  via  a  specific  external  interface. 


1 1 .2. 16. 1  TSPECTS  Data  Packets,  Format  0  (NMEA-RTCM) 

Any  GPS  data  as  defined  by  the  National  Marine  Electronics  Association  (NMEA)  and 
Radio  Technical  Commission  for  Maritime  Services  (RTCM)  standards  will  be  encapsulated  in 
the  Format  0  packet.  The  NMEA  and  RTCM  standards  specify  the  electrical  signal 
requirements,  data  transmission  protocol,  and  message/sentence  formats  for  GPS  data.  These 
formatting  standards  will  not  be  detailed  in  this  chapter,  but  they  will  be  referenced  as  required 
for  clarity. 

The  TSPECTS  Data  Packet,  Format  0  (NMEA-RTCM)  will  not  support  proprietary 
messages  or  sentences;  therefore,  any  data  containing  these  will  be  considered  non-compliant 
with  this  standard. 


A  packet  with  n  NMEA-RTCM  data  has  the  basic  structure  as  Table  11-50. 

Table  11-50.  NMEA-RTCM  Data  Packet  Format 


Isb 
_0 

Packet  Header _ 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  15-0) 

(Optional)  Intra-Packet  Time  Stamp  for  Data  I  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp  for  Data  I  (Bits  47-32) 

(Optional)  Intra-Packet  Time  Stamp  for  Data  I  (Bits  63-48) 

Intra-Packet  Data  Header  (Bits  15-0) 

Intra-Packet  Data  Header  (Bits  31-16) 

Byte  2  Byte  I 


Filler  (if  n  is  Odd) Byte  N 


(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  15-0) 
(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  31-16) 
(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  47-32) 
(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  63-48) 
Intra-Packet  Data  Header  (Bits  15-0) 


msb 

15 
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Intra-Packet  Data  Header  (Bits  31-16) 

B3Te  2 

Byte  1 

Eiller  (if  n  is  Odd) 

Byte  N 

Packet  Trailer 

a.  NMEA-RTCM  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each 
NMEA-RTCM  data  packet  begins  with  a  CSDW  as  shown  in  Eigure  11-85. 
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Eigure  1 1-85.  NMEA-RTCM  Packet  Channel-Specific  Data  Word 


•  IPTS.  Bit  3 1  indicates  whether  the  IPTS  is  enabled. 

0  =  IPTS  not  enabled 
1  =  IPTS  enabled 

•  TYPE.  Bits  30-27  indicate  the  type  of  data  NMEA-RTCM  contains  within  the 
packet. 

0000  =  NMEA  0183 
0001  =NMEA0183-HS 
0010  =  NMEA  2000 
0011  =RTCM  SC104 
0010  -1111=  Reserved 

•  RESERVED.  Bits  26-0  are  reserved  and  shall  be  zero-filled. 

b.  NMEA-RTCM  Intra-Packet  Time  Stamp.  If  enabled  the  optional  IPTS  is  inserted  before 
each  NMEA-RTCM  message.  The  length  of  the  IPTS  is  8  bytes  (64  bits)  positioned 
contiguously,  in  the  following  sequence  (Eigure  11-86). 

msb  Isb 

^1 _ 0_ 

(Optional)  Time  (ESEW) _ 

(Optional)  Time  (MSEW) _ 

Eigure  11-86.  NMEA-RTCM  Intra-Packet  Time  Stamp 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  NMEA-RTCM 
data.  Eirst  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following 
values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit.  Bits  31  to  16  in  the 
second  long  word  (MSEW)  will  be  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit. 
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c.  NMEA-RTCM  Intra-Packet  Data  Header.  The  length  of  the  IPDH  is  fixed  at  4  bytes  (32 
bits)  positioned  contiguously,  in  the  following  sequence  (Figure  11-87). 
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Figure  11-87.  NMFA-RTCM  Intra-Packet  Data  Header 


•  RESERVED.  Bits  31-16  are  reserved. 

•  EENGTH.  Bits  15-0  indicate  the  length  of  the  message  in  bytes. 


1 1 .2. 16.2  TSPI  Data  Packets,  Format  1  (EAG  ACMI) 

Air  Combat  Maneuvering  Instrumentation  (ACMI)  data  as  defined  by  the  European  Air 
Group  (EAG)  interface  control  document  (ICD)  DF29125^^for  post-mission  interoperability  will 
be  encapsulated  in  the  Format  1  packet.  The  EAG  ACMI  ICD  defines  the  data  contents  and 
organization.  Electrical  signal  requirements  and  data  transmission  protocol  are  not  defined  in 
DF29125  or  in  this  Chapter  1 1  format.  The  data  type  will  be  8-bit  ASCII.  A  packet  of  EAG 
ACMI  data  has  the  basic  structure  of  Table  11-51. 


Table  11-51.  EAG  ACMI  Data  Packet  Format 


Isb 
_0 

Packet  Header 

_ Channel-Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

(Optional)  Intra-Packet  Time  Stamp-Data  Block  1  (Bits  15-0) 

(Optional)  Intra-Packet  Time  Stamp-Data  Block  1  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp-Data  Block  1  (Bits  47-32) 

(Optional)  Intra-Packet  Time  Stamp-Data  Block  1  (Bits  63-48) 

Intra-Packet  Data  Header 

(Optional)  Static  Data _ _ 

Byte  2  Byte  1 


Filler  (if  n  is  Odd) _  Byte  N 

Packet  Trailer 


msb 

15 


a.  EAG  ACMI  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  EAG 
ACMI  data  packet  begins  with  a  CSDW  as  shown  in  Figure  11-88. 


European  Air  Group.  “European  Air  Group  Interface  Control  Document  for  Post  Mission  Interoperability.” 
DE29 125  Draft  A  Issue  01.  July  2004.  Retrieved  27  April  2017.  Available  to  RCC  members  with  Private  Portal 
access  at  https://wsdmext.wsmr.armv.mil/site/rccpri/Limited  Distribution  References/DP29125.pdf. 
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Figure  1 1-88.  BAG  ACMI  Packet  Channel-Specific  Data  Word 


•  IPTS.  Bit  3 1  indicates  whether  the  IPTS  is  enabled. 

0  =  IPTS  not  enabled 
1  =  IPTS  enabled 

•  CONTENT.  Bits  30-29  indicate  the  content  of  the  EAG  ACMI  data  within  the 
packet. 

00  =  TSPI  data  only  (no  static  data  or  pod  ID) 

01  =  Contains  pod  ID  and  static  data 
10  -  11  =  Reserved 

•  RESERVED.  Bits  28-0  are  reserved. 

b.  EAG  ACMI  Intra-Packet  Time  Stamp.  If  enabled  the  optional  IPTS  is  inserted  before  the 
EAG  ACMI  data  block.  The  length  of  the  IPTS  is  8  bytes  (64  bits)  positioned 
contiguously,  in  the  following  sequence  (Eigure  1 1-89). 

msb  Isb 

^1 _ 0_ 

(Optional)  Time  (ESEW) _ 

(Optional)  Time  (MSEW) _ 

Eigure  1 1-89.  EAG  ACMI  Data  Intra-Packet  Time  Stamp 

•  EAG  ACMI  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the 
EAG  ACMI  TSPI  data.  Pod  ID  and  static  data  will  not  be  time-tagged  but  will 
precede  the  TSPI  data  in  the  packet.  Eirst  long  word  bits  31-0  and  second  long  word 
bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  TSPI  data  bit.  Bits  31  to  16  in  the 
second  long  word  (MSEW)  of  the  IPTS  will  be  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit. 

c.  EAG  ACMI  Intra-Packet  Data  Header.  The  length  of  the  IPDH  is  fixed  at  4  bytes  (32 
bits)  positioned  contiguously,  in  the  following  sequence  (Eigure  11-90). 
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EENGTH 

Eigure  1 1-90.  EAG  ACMI  Intra-Packet  Data  Header 


•  RESERVED.  Bits  31-16  are  reserved. 
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•  LENGTH.  Bits  15-0  indicate  the  length  of  the  message  in  bytes. 


1 1 .2. 16.3  TSPI  Data  Packets,  Format  2  (ACTTS) 

Air  Combat  Test  and  Training  System  (ACTTS)  data  as  defined  by  the  US  AF  ACTTS 
interface  specification  WMSP  98-01  will  be  encapsulated  in  the  Format  2  packet.  The  ACTTS 
interface  specification  defines  the  unique  signal  interface  requirements  for  the  air-to-air,  air-to- 
ground,  ground-to-air  data  links,  and  aircraft  information  subsystem  recording  formats.  The 
ACTTS  WMSP  98-01  establishes  the  requirements  for  the  information  recorded  on  the  different 
data  transfer  units  used  by  the  various  ACTTS  airborne  subsystems  to  support  both  tethered  and 
rangeless  operations. 


When  encapsulating  ACTTS  message/word  format,  data  messages  or  words  will  not  span 
packets.  Each  new  packet  will  start  with  a  full  message  and  not  a  partial  message  or  word.  A 
packet  of  ACTTS  data  has  the  basic  structure  of  Table  11-52. 


Table  11-52.  ACTTS  Data  Packet  Format 


msb  Isb 

15 _ 0 

Packet  Header _ 

_ Channel-Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

_ (Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  15-0) _ 

(Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  47-32) 

(Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  63-48) 


Intra-Packet  Data  Header 


Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  N 

(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  15-0) 
(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  31-16) 
(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  47-32) 
(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  63-48) 


Intra-Packet  Data  Header 


Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  N 

Packet  Trailer 

Range  Instrumentation  System  Program  Office,  Air  Armament  Center.  “Interface  Specification  for  the  USAF  Air 
Combat  Test  and  Training  System  (ACTTS)  Air-to-Ground,  Air-to-Air,  Ground-to-Air  Data  Links,  and  AIS 
Recording  Formats."  WMSP  98-01,  Rev  A,  Chg  1.  19  May  2003.  Retrieved  27  April  2017.  Available  to  RCC 
members  with  Private  Portal  access  at 

https://wsdmext.wsmr.armv.mil/site/rccpri/Limited  Distribution  ReferencesAVMSP  98-01. doc. 
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a.  ACTTS  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  ACTTS 
data  packet  begins  with  a  CSDW  as  shown  in  Figure  11-91. 
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Figure  11-91.  ACTTS  Packet  Channel-Specific  Data  Word 


•  IPTS.  Bit  3 1  indicates  whether  the  IPTS  is  enabled. 

0  =  IPTS  not  enabled 
1  =  IPTS  enabled 

•  FORMAT.  Bits  30-27  indicate  the  ACTTS  format  type  of  data  contained  within  the 
packet. 

0000  =  Kadena  Interim  Training  System  (KITS)  Recording  Formats 
0001  =  Alpena  KITS  Recording  Formats 

0010  =  USAF  Europe  Rangeless  Interim  Training  System  Recording  Formats 
0011=  Alaska  ACTS  Upgrade  Recording  Formats 

0100  =  Goldwater  Range  Mission  and  Debriefing  System  Recording  Formats 
0101  =  P4RC  Recording  Formats 

01 10  =  Nellis  ACTS  Range  Security  Initiative  Recording  Formats 
0111  =  P4RC-I-P5  CTS  Participant  Subsystem  Recording  Formats 

1000  =  P5  CTS  Recording  Formats 

1001  -1111  =  Reserved 

•  RESERVED.  Bits  26-0  are  reserved. 

b.  ACTTS  Intra-Packet  Time  Stamp.  If  enabled  the  optional  IPTS  is  inserted  before  each 
ACTTS  message.  The  length  of  the  IPTS  is  8  bytes  (64  bits)  positioned  contiguously,  in 
the  following  sequence  (Eigure  11-92). 

msb  Isb 

^1 _ 0_ 

(Optional)  Time  (ESEW) _ 

(Optional)  Time  (MSEW) _ 

Eigure  1 1-92.  ACTTS  Data  Intra-Packet  Time  Stamp 

These  8  bytes  indicate  the  time  tag  of  the  ACTTS  data.  Eirst  long  word  bits  31-0  and 
second  long  word  bits  31-0  indicate  the  following  values. 

•  The  48-bit  RTC  that  corresponds  to  the  first  ACTTS  data  bit.  Bits  31  to  16  in  the 
second  long  word  (MSEW)  of  the  IPTS  will  be  zero-filled;  or 

•  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item  g). 
The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  tag  shall  be  correlated  to  the  first  data  bit. 

c.  ACTTS  Intra-Packet  Data  Header.  The  length  of  the  IPDH  is  fixed  at  4  bytes  (32  bits) 
positioned  contiguously,  in  the  following  sequence  (Eigure  11-93). 
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Figure  1 1-93.  ACTTS  Data  Intra-Packet  Data  Header 


•  RESERVED.  Bits  31-16  are  reserved. 

•  EENGTH.  Bits  15-0  indicate  the  length  of  the  message  in  bytes. 
11.2.17  Controller  Area  Network  Bus  Packets 


1 1 .2. 17. 1  Controller  Area  Network  Bus  Data  Packet,  Eormat  0 

Data  from  one  or  more  controller  area  network  (CAN)  bus  interfaces  are  placed  into  a 
CAN  bus  data  packet  format  as  shown  in  Table  11-53. 


Table  11-53.  Controller  Area  Network  Bus  Data  Packet,  Format  0 

msb  Isb 

15 _ 0 

Packet  Header _ 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  15-0) _ 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  47-32) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  63-48) 

Intra-Packet  Message  Header  for  Msg  1  (Bits  15-0) _ 

Intra-Packet  Message  Header  for  Msg  1  (Bits  31-16) _ 

Intra-Packet  ID  Word  for  Msg  1  (Bits  47-32) 


Intra-Packet  ID  Word  for  Msg  1  (Bits  63-48) 


Msg  1  Byte  2 

Msg  1  Byte  1 

Eiller  (if  n  is  Odd) 

Msg  1  Byte  n 

Intra-Packet  Time  Stamp  for  Msg  n  (Bits  15-0) 
Intra-Packet  Time  Stamp  for  Msg  n  (Bits  31-16) 
Intra-Packet  Time  Stamp  for  Msg  n  (Bits  47-32) 
Intra-Packet  Time  Stamp  for  Msg  n  (Bits  63-48) 
Intra-Packet  Message  Header  for  Msg  n  (Bits  15-0) 
Intra-Packet  Message  Header  for  Msg  n  (Bits  31-16) 
Intra-Packet  ID  Word  for  Msg  n  (Bits  47-32) 


Intra-Packet  ID  Word  for  Msg  n  (Bits  63-48) 


Msg  n  Byte  2 

Msg  n  Byte  1 

Eiller  (if  m  is  odd) 

Msg  n  Byte  m 

Packet  Trailer 
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a.  CAN  Bus  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  CAN 
bus  data  packet  begins  with  a  CSDW.  Figure  11-94  displays  a  complete  CAN  bus 
CSDW. 
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Figure  1 1-94.  Complete  CAN  Bus  Format  0  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-16  are  reserved. 

•  N  of  Messages.  Bits  15-0  contain  a  binary  value  indicating  the  number  of  messages 
included  in  the  packet. 

b.  CAN  Bus  Data  Intra-Packet  Header.  After  the  CSDW,  CAN  bus  data  is  inserted  into  the 
packet.  Each  CAN  bus  message  is  preceded  by  an  IPH  that  has  both  an  IPTS  and  an 
intra-packet  message  header  (IPMH)  and  an  intra-packet  ID  word.  The  length  of  the  IPH 
is  fixed  at  16  b3Tes  (128  bits)  positioned  contiguously,  in  the  sequence  shown  in  Figure 
11-95. 

msb 

^1 _ 

Intra-Packet  Time  Stamp  (LSLW) 

Intra-Packet  Time  Stamp  (MSLW) 

Intra-Packet  Message  Header 
Intra-Packet  ID  Word 
Figure  1 1-95.  CAN  Bus  Data  Format  0  Intra-Packet  Data  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  message  data. 
First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following 
values. 

o  The  RTC  that  corresponds  to  the  first  data  bit  in  the  message  with  bits  31  to 
16  in  the  second  long  word  zero-filled;  or 

o  Time,  if  enabled  by  bit  7  in  the  packet  flags.  Time  format  is  indicated  by  bits 
2  and  3  in  the  packet  flags  and  to  the  first  data  bit  in  the  message. 


•  Intra-Packet  Message  Header.  The  IPMH  is  an  information  word  that  is  inserted  into 
the  packet  with  the  format  shown  in  Figure  11-96. 
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MESSAGE  EENGTH 

Figure  1 1-96.  Intra-Packet  Message  Header 


o  Data  Error  (DE).  Bit  3 1  indicates  bad  data  bits  as  determined  by  parity, 
checksums,  or  CRC  words  received  with  the  data. 

0  =  No  data  error  has  occurred 


Isb 

0 


II-III 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


1  =  Data  error  has  occurred 

o  Format  Error  (FE).  Bit  30  indicates  a  protocol  error,  such  as  out-of-sequence 
data  or  length  errors. 

0  =  No  format  error 
1  =  Format  error  encountered 

o  Reserved.  Bits  29-24  are  reserved. 

o  Subchannel.  Bits  23-16  contain  a  binary  value  that  represents  the  subchannel 
number  belonging  to  the  message  that  follows  the  ID  word  when  the  channel 
ID  in  the  packet  header  defines  a  group  of  subchannels.  Zero  means  first 
and/or  only  subchannel,  which  is  valid  for  the  CAN  bus. 

o  Reserved.  Bits  15-4  are  reserved. 

o  Message  Length.  Bits  3-0  contain  a  binary  value  representing  the  length  of 
the  number  of  the  valid  bytes  in  the  rest  of  the  message  that  follows  the 
IPMH.  The  message  length  will  be  4-12  bytes  (4  bytes  for  the  intra-packet  ID 
word  -I-  0-8  bytes  data  content  of  the  CAN  bus  message). 

•  Intra-Packet  ID  Word.  The  intra-packet  ID  word  contains  the  CAN  bus  message  ID 
word  transmitted  on  the  bus.  This  word  precedes  the  message  and  is  inserted  into  the 
packet  with  the  format  shown  in  Figure  11-97. 
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CAN  Bus  ID 

Figure  1 1-97.  Intra-Packet  ID  Word 


o  IDE  (bit  31  of  the  32-bit  CAN  ID  word):  use  extended  CAN  identifier. 

0=1 1 -bit  standard  CAN  identifier  (CAN  ID  word  bits  1 0-0) 

1  =  29-bit  extended  CAN  identifier  (CAN  ID  word  bits  28-0) 

o  RTR  (bit  30  of  the  CAN  ID  word):  Remote  transfer  request  bit. 

o  CAN  Bus  ID:  The  CAN  bus  ID  transmitted  in  the  message. 

When  using  the  1 1 -bit  standard  CAN  identifier,  bits  29-11  of  the  32-bit  CAN 
ID  word  are  unused.  For  the  29-bit  extended  CAN  identifier  all  the  29  bits, 
28-0,  are  used. 

•  CAN  Bus  Message.  The  CAN  bus  message  is  placed  behind  the  CAN  bus  IPH.  The 
message  can  consist  up  to  8  bytes,  which  is  placed  in  0-4  x  16-bit  data  words.  Figure 
11-98  displays  a  CAN  bus  message  format. 


BYTE  2 

BYTE  I 

Eiller  (if  n  is  Odd) 

BYTEn 

dgure  1 1-98.  CAN  Bus  Format  0  Message 
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1 1 .2. 17.2  Controller  Area  Network  Bus  Data  Packet,  Format  1 
This  section  is  reserved  for  future  development 

11.2.18  Fibre  Channel  Packets 


11.2.18.1  Fibre  Channel  Data  Packets,  Format  0  (FC-PH  Layer) 

Data  from  a  Fibre  Channel  port  can  be  placed  into  a  Fibre  Channel  Data  Packet  Format  0 
as  shown  in  Table  11-54. 


Table  11-54.  Fibre  Channel  Data  Packet,  Format  0 

msb 

\5 _ 0 

_ PACKET  HEADER _ 

_ CHANNEE-SPECIEIC  DATA  (BITS  15-0) _ 

_ CHANNEE-SPECIEIC  DATA  (BITS  31-16) _ 

INTRA-PACKET  HEADER  EQR  EIBRE  CHANNEE  ERAME  1  (BITS  15-0) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEE  ERAME  1  (BITS  31-16) 
INTRA-PACKET  HEADER  EQR  EIBRE  CHANNEE  ERAME  1  (BITS  47-32) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEE  ERAME  1  (BITS  63-48) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEE  ERAME  1  (BITS  79-64) 


INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEE  ERAME  1  (BITS  95-80) 


ERAME  BYTE  2 

ERAME  BYTE  1 

: 

: 

EIEEER  (IE  n  IS  ODD) 

ERAME  BYTE  n 

INTRA-PACKET  HEADER  EQR  EIBRE  CHANNEE  ERAME  n  (BITS  15-0) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEE  ERAME  n  (BITS  31-16) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEE  ERAME  n  (BITS  47-32) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEE  ERAME  n  (BITS  63-48) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEE  ERAME  n  (BITS  79-64) 


INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEE  ERAME  n  (BITS  95-80) 


ERAME  BYTE  2 

ERAME  BYTE  1 

: 

: 

EIEEER  (IE  n  IS  ODD) 

ERAME  BYTE  n 

PACKET  TRAIEER 


a.  Eibre  Channel  Data  Packet  Channel- Specific  Data  Word.  The  packet  body  portion  of 
each  Eibre  Channel  data  packet  begins  with  a  CSDW.  It  indicates  the  format  and  how 
many  Eibre  Channel  frames  are  placed  in  the  packet  body.  The  CSDW  is  formatted  for 
the  complete  type  of  packet  body  as  shown  in  Eigure  11-99. 
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EORMAT 

RESERVED 

NUMBER  OE  ERAMES 

Eigure  1 1-99.  Eibre  Channel  Data  Packet  Channel-Specific  Data  Word 
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•  Format.  Bits  31-28  indicate  the  type  of  Fibre  Channel  data  packet. 

0000  =  FC-PH  physical  layer  ANSI  X3T1 1  Project  755-D 
0001  -  1111  =  Reserved 

•  Reserved.  Bits  27-16  are  reserved. 

•  Number  of  Frames.  Bits  15-0  contain  a  binary  value  that  represents  the  number  of 
complete  or  stripped  Fibre  Channel  frames  included  in  the  packet. 

b.  Fibre  Channel  Data  Packet  Format  0  Intra-Packet  Header.  After  the  channel-specific 
data,  complete  or  stripped  Fibre  Channel  frames  are  inserted  into  the  packet.  Each 
complete  or  stripped  Fibre  Channel  frame  is  preceded  by  an  IPH  that  has  both  an  IPTS 
and  an  IPDH  containing  a  frame  ID  word.  The  length  of  the  IPH  is  fixed  at  12  bytes  (96 
bits)  positioned  contiguously,  in  the  following  sequence  as  shown  in  Figure  11-100. 

msb  Isb 

^1 _ 0_ 

TIME  (LSLW) _ 

TIME  (MSEW) _ 

ERAME  ID  WORD _ 

Eigure  11-100.  Eibre  Channel  Data  Eormat  0  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  complete  or 
stripped  Eibre  Channel  frame.  Eirst  long  word  bits  31-0  and  second  long  word  bits 
31-0  indicate  the  following  values: 

o  The  48-bit  RTC  that  corresponds  to  the  first  bit  after  the  CSDW  of  the 
complete  or  stripped  Eibre  Channel  frame  with  bits  31  to  16  in  the  second 
long  word  zero  filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  of  the  complete  or  stripped  Eibre  Channel  frame. 


•  Erame  ID  Word.  The  frame  ID  word  is  an  identification  word  that  precedes  the  Eibre 
Channel  frame  and  is  inserted  into  the  packet  with  the  format  shown  in  Eigure 
11-101. 
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CE 
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SM 
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EOE 
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EE 

Eigure  1 1-101.  Eibre  Channel  Data  Eormat  0  Intra-Packet  Erame  ID  Word 


o  Eraming  Error  (EE).  Bit  31  indicates  a  framing  error  such  as  EOE  missing. 
0  =  No  framing  error. 

1  =  Eraming  error  detected  in  Eibre  Channel  frame, 
o  CRC  Error  (CE).  Bit  30  indicates  a  CRC  error. 

0  =  No  CRC  error. 
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1  =  CRC  error  detected  in  Fibre  Channel  frame, 
o  Overrun  Error  (OE).  Bit  29  indicates  a  buffer  overrun  error. 

0  =  No  overrun  error. 

1  =  Overrun  error  detected  prior  to  this  Fibre  Channel  frame. 

o  Stripped  Mode  (SM).  Bit  28  indicates  whether  the  Fibre  Channel  frame 
delimiters,  header,  and  CRC  are  removed,  resulting  in  a  stripped  Fibre 
Channel  frame  with  data  payload  only. 

0=  Stripped  mode.  Only  Fibre  Channel  data  payload  is  present. 

1=  Non-stripped  mode.  Complete  Fibre  Channel  frame  is  present. 

o  Content  (CONTENT).  Bits  27-26  specify  the  type  of  the  Fibre  Channel 
frame.  Content  bits  are  only  valid  when  in  non-stripped  mode  (i.e.,  bit  28  = 

1). 

00  =  Complete  data  frame 

01  =  Complete  link  control  frame 

10-11  =  Reserved 

o  Topology  (TOP).  Bits  25-24  specify  the  Fibre  Channel  topology  of  frame 
from  the  port. 

00  =  Passive 
01-11  Reserved 

o  Reserved.  Bits  23-19  are  reserved. 

o  End  of  Frame  (EOF).  Bits  18-16  indicate  a  binary  value  for  the  end-of-frame 
delimiter  that  terminated  the  Fibre  Channel  frame.  This  is  applicable  only  in 
stripped  mode.  Values  are  as  follows: 

000  -  (0):  EOF  normal  (EOFn) 

001  -  (1):  EOF  terminate  (EOFt) 

010  -  (2):  EOF  disconnect  terminate  (EOFdt) 

01 1  -  (3):  EOF  abort  (EOFa) 

100  -  (4):  EOF  normal  invalid  (EOFni) 

101  -  (5):  EOF  disconnect  terminate  Invalid  (EOFdti) 

1 10  -  (6):  EOF  remove  terminate  (EOFrt) 

1 1 1  -  (7):  EOF  remove  terminate  invalid  (EOFrti) 

o  Start  of  Frame  (SOF).  Bits  15-12  indicate  a  binary  value  for  the  start-of- frame 
delimiter  that  began  the  Fibre  Channel  frame.  This  is  applicable  only  in 
stripped  mode.  Values  are  as  follows: 

0000  -  (0):  SOF  connect  class- 1  (SOFcl) 

0001  -  (1):  SOF  initiate  class-1  (SOFil) 

0010  -  (2):  SOF  normal  class-1  (SOFnl) 

0011  -  (3):  SOF  initiate  class-2  (SOFi2) 

0100  -  (4):  SOF  normal  class-2  (SOFn2) 

0101  -  (5):  SOF  initiate  class-3  (SOFi3) 

01 10  -  (6):  SOF  normal  class-3  (SOFn3) 
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0111  -  (7):  SOF  activate  class-4  (SOFc4) 

1000  -  (8):  SOF  initiate  class-4  (SOFi4) 

1001  -  (9):  SOF  normal  class-4  (SOFn4) 

1010  -  (A):  SOF  fabric  (SOFf) 

1011  -  llll(B-F):  Reserved 

o  Frame  Length.  In  stripped  mode,  bits  11-0  indicate  the  length  of  the  frame’s 
data  payload  in  bytes  (excluding  the  SOF  and  EOF  delimiters  and  CRC  word). 
In  stripped  mode,  maximum  length  is  21 12  bytes.  In  non-stripped  mode,  bits 
11-0  indicate  the  length  of  the  entire  Fibre  Channel  frame  in  bytes.  The  frame 
length  must  be  divisible  by  4. 


11.2.18.2  Fibre  Channel  Data  Packets,  Format  1  (FC-FS  Layer) 

Data  from  a  Fibre  Channel  port  can  be  placed  into  a  Fibre  Channel  Data  Packet  Format  1 . 
In  this  format,  the  Fibre  Channel  frames  placed  in  the  packet  include  only  the  frame  header  and 
data  field.  The  Start-of-Frame  delimiter,  End-of-Frame  delimiter,  and  CRC  word  of  the  frame 
are  excluded.  Fibre  Channel  Data  Packet  Format  1  is  shown  in  Table  11-55. 


Table  11-55.  Fibre  Channel  Data  Packet,  Format  1 


msb  Isb 

15 _ 0 

_ PACKET  HEADER _ 

_ CHANNEL-SPECIEIC  DATA  (BITS  15-0) _ 

_ CHANNEL-SPECIEIC  DATA  (BITS  31-16) _ 

INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEL  ERAME  1  (BITS  15-0) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEL  ERAME  1  (BITS  31-16) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEL  ERAME  1  (BITS  47-32) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEL  ERAME  1  (BITS  63-48) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEL  ERAME  1  (BITS  79-64) 


INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEL  ERAME  1  (BITS  95-80) 


ERAME  BYTE  2 

ERAME  BYTE  1 

: 

: 

ERAME  BYTE  n 

ERAME  BYTE  n-1 

INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEL  ERAME  n  (BITS  15-0) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEL  ERAME  n  (BITS  31-16) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEL  ERAME  n  (BITS  47-32) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEL  ERAME  n  (BITS  63-48) 
INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEL  ERAME  n  (BITS  79-64) 


INTRA-PACKET  HEADER  EOR  EIBRE  CHANNEL  ERAME  n  (BITS  95-80) 


ERAME  BYTE  2 

ERAME  BYTE  1 

: 

: 

ERAME  BYTE  n 

ERAME  BYTE  n-1 

PACKET  TRAILER 
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a.  Fibre  Channel  Data  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of 
each  Fibre  Channel  Data  Packet  begins  with  a  CSDW.  It  indicates  how  many  Fibre 
Channel  frames  are  placed  in  the  packet  body.  The  CSDW  is  formatted  for  the  complete 
type  of  packet  body  as  shown  in  Figure  11-102. 
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RESERVED 

NUMBER  OE  ERAMES 

Figure  1 1-102.  Fibre  Channel  Data  Packet  Channel-Specific  Data  Word 


Format 

•  Reserved.  Bits  31-16  are  reserved. 

•  Number  of  Frames.  Bits  15-0  contain  a  binary  value  that  represents  the  number  of 
Fibre  Channel  frames  included  in  the  packet. 

b.  Fibre  Channel  Data  Packet  Format  1  Intra-Packet  Header.  After  the  channel-specific 
data,  Fibre  Channel  frames  are  inserted  into  the  packet.  Each  Fibre  Channel  frame  is 
preceded  by  an  IPH  that  has  both  an  IPTS  and  an  IPDH  containing  a  frame  status  word. 
The  length  of  the  IPH  is  fixed  at  12  bytes  (96  bits)  positioned  contiguously,  in  the 
following  sequence  as  shown  in  Figure  11-103. 

msb  Isb 

^1 _ 0_ 

TIME  (LSLW) _ 

TIME  (MSEW) _ 

ERAME  STATUS  WORD _ 

Eigure  1 1- 103.  Eibre  Channel  Data  Eormat  1  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  Eibre  Channel 
frame.  The  timestamp  is  sampled  and  latched  at  the  end  of  the  last  bit  of  the  Start-of- 
Erame  delimiter.  Eirst  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate 
the  following  values: 

o  The  48-bit  RTC  that  corresponds  to  the  first  bit  after  the  CSDW  of  the  Eibre 
Channel  frame  with  bits  31  to  16  in  the  second  long  word  zero  filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  Time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g). 

•  Erame  Status  Word.  The  frame  status  word  precedes  the  Eibre  Channel  frame  and  is 
inserted  into  the  packet  with  the  format  shown  in  Eigure  11-104. 
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EE 

CE 

OE 

RESERVED 

EOE 

SOE 

ERAME  EENGTH 

Eigure  11-104.  Eibre  Channel  Data  Eormat  1,  (EC-ES  Eayer)  Intra-Packet 


Erame  Status  Word 
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o  Framing  Error  (FE).  Bit  3 1  is  used  to  indicate  a  framing  error,  such  as  EOF 
missing. 

0  =  No  framing  error. 

1  =  Framing  error  detected  in  Fibre  Channel  frame, 
o  CRC  Error  (CE).  Bit  30  indicates  a  CRC  error  was  detected. 

0  =  No  CRC  error. 

1  =  CRC  error  detected  in  Eibre  Channel  frame, 
o  Overrun  Error  (OE).  Bit  29  is  used  to  indicate  a  buffer  overrun  error. 

0  =  No  overrun  error. 

1  =  Overrun  error  detected  prior  to  this  Eibre  Channel  frame, 
o  Reserved.  Bits  28-19  are  reserved. 

o  End  of  Erame  (EOE).  Bits  18-16  indicate  a  binary  value  for  the  End-Of- 
Erame  delimiter  that  terminated  the  Eibre  Channel  frame.  Values  are  as 
follows: 

000  -  (0):  EOE  normal  (EOEn) 

001  -  (1):  EOE  terminate  (EOEt) 

010  -  (2):  EOE  disconnect  terminate  (EOEdt) 

01 1  -  (3):  EOE  abort  (EOEa) 

100  -  (4):  EOE  normal  invalid  (EOEni) 

101  -  (5):  EOE  disconnect  terminate  invalid  (EOEdti) 

1 10  -  (6):  EOE  remove  terminate  (EOErt) 

1 1 1  -  (7):  EOE  remove  terminate  invalid  (EOErti) 

o  Start  of  Erame  (SOE).  Bits  15-12  indicate  a  binary  value  for  the  Start-Of- 
Erame  delimiter  that  began  the  Eibre  Channel  frame.  Values  are  as  follows: 

0000  -  (0):  SOE  connect  class- 1  (SOEcl) 

0001  -  (1):  SOE  initiate  class-1  (SOEil) 

0010  -  (2):  SOE  normal  class-1  (SOEnl) 

001 1  -  (3):  SOE  initiate  class-2  (SOEi2) 

0100  -  (4):  SOE  normal  class-2  (SOEn2) 

0101  -  (5):  SOE  initiate  class-3  (SOEi3) 

01 10  -  (6):  SOE  normal  class-3  (SOEn3) 

0111  -  (7):  SOE  activate  class-4  (SOEc4) 

1000  -  (8):  SOE  initiate  class-4  (SOEi4) 

1001  -  (9):  SOE  normal  class-4  (SOEn4) 

1010  -  (A):  SOE  fabric  (SOEf) 

1011  -  llll(B-E):  Reserved 

o  Erame  Eength.  Bits  11-0  indicate  the  combined  length  of  the  Eibre  Channel 
frame  header  and  data  fields  (excludes  the  SOE,  EOE  delimiters,  and  CRC 
word  of  the  frame)  in  bytes.  This  field  must  be  evenly  divisible  by  4. 
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APPENDIX  11-A 
Definitions 

The  following  are  definitions  that  are  used  in  this  standard  and  are  provided  as  a  means  of 

removing  ambiguities  within  the  standard. 

Absolute  Time:  A  hypothetical  time  that  either  runs  at  the  same  rate  for  all  the  observers  in  the 
universe  or  the  rate  of  time  each  observer  can  be  scaled  to  by  multiplying  the  observer’s 
rate  by  a  constant. 

Byte:  A  contiguous  set  of  8  bits  that  are  acted  on  as  a  unit. 

Channel-Specific  Data  Word:  A  required  word  for  each  data  type  channel  that  has  data- specific 
information. 

Data  Streaming:  Streaming  of  current  value  data  whether  it  is  being  recorded  or  not,  and 

playback  streaming  of  recorded  data  from  a  file.  Data  streaming  sends  the  data  to  one  or 
more  destinations  simultaneously  (e.g.,  recording  media,  recorder  data  interfaces). 

Extended  Relative  Time  Counter:  A  1-GHz  extension  to  the  existing  10-MHz  RTC. 

Long  Word:  A  contiguous  set  of  32  bits  that  are  acted  on  as  a  unit. 

Mandatory:  Defines  a  mandatory  requirement  of  this  standard  for  full  compliancy.  Mandatory 
requirements  as  defined  in  this  standard  are  based  on  the  use  of  “shall”. 

Multiplexer:  The  entity  that  includes  all  the  inputs,  control  interfaces,  and  functionality  required 
to  properly  record  data. 

Packet:  Encapsulates  a  block  of  observational  and  ancillary  application  data  to  be  recorded. 

Packet  Generation:  The  placing  of  observational  and  ancillary  data  into  a  packet. 

Recorder:  Is  used  where  a  function  or  requirement  shall  apply  to  both  an  on-board  recorder  and 
a  ground-based  recorder. 

Recording:  Is  defined  as  the  time  interval  from  first  packet  generated  to  the  last  packet 

committed  to  the  recorder  media.  Packet  generation  time  and  stream  commit  time,  as 
defined  within  the  standard,  apply. 

Session:  Period  of  time  during  which  data  is  acquired,  processed  and/or  stored.  Typically 
corresponds  to  a  recording  (q.v.) 

Setup  Record:  TMATS  lAW  Chapter  9  annotated  in  the  Computer-Generated  Data,  Format  0 
packet. 

Stream:  All  packets  from  all  enabled  channels  (including  computer-generated  data)  that  are 
generated. 

Stream  Commit  Time:  The  time  span  in  which  all  generated  packets  must  be  committed  to  a 
stream. 

Word:  A  contiguous  set  of  16  bits  acted  on  as  a  unit. 
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CHAPTER  21 

Telemetry  Network  Standard  Introduction 


21.1  Introduction 

The  Telemetry  Network  Standard  (TmNS)  erosses  IRIG  106,  ehapters  21  through  28. 

This  ehapter  introduees  fundamental  concepts  and  terminology  used  in  the  subsequent  chapters. 
Additionally,  this  chapter  provides  guidance  as  to  which  of  the  remaining  chapters  might  be  of 
most  interest  for  a  particular  reader.  In  order  to  guide  the  reader  toward  the  chapters  of  further 
interest,  the  applicable  chapters  are  referenced  throughout  this  chapter  as  it  introduces  concepts 
and  terminology.  A  quick  synopsis  of  chapters  22  through  28  is  provided  below. 

•  IRIG  106  Chapter  22:  Network-Based  Protocol  Suite 

The  TmNS  approach  leverages  existing  standardized  Internet  protocols  to  serve  as  the 
core  set  of  communication  protocols.  The  TmNS’s  network-based  protocol  suite  and 
a  large  portion  of  the  Transmission  Control  Protocol  (TCP)/Internet  Protocol  (IP) 
Protocol  Suite  (also  known  as  the  Internet  Protocol  Suite)  along  with  other  supporting 
technologies  (e.g.,  underlying  data  link  and  physical  layer  technologies)  are  described 
in  this  chapter. 

•  IRIG  106  Chapter  23:  Metadata  Configuration 

This  chapter  describes  system  configuration  data  for  TmNS-based  systems.  It  allows 
them  to  be  described  in  a  common  fashion,  and  it  provides  the  means  for  describing 
the  configuration  of  the  components  in  a  telemetry  system,  as  well  as  their  logical  and 
physical  interrelationships.  This  chapter  defines  a  language,  the  Metadata 
Description  Language  (MDL),  which  has  a  syntax  that  defines  vocabulary  and 
sentence  structure,  while  the  MDL  semantics  provide  meaning.  The  MDL  provides  a 
common  exchange  language  that  facilitates  the  interchange  of  configuration 
information  between  telemetry  system  components. 

•  IRIG  106  Chapter  24:  Message  Formats 

The  TmNS  has  defined  several  message  structures  unique  for  its  use.  This  chapter 
describes  the  message  formats  of  TmNS-specific  messages. 

•  IRIG  106  Chapter  25:  Management  Resources 

The  TmNS  defines  Management  Resources  as  resources  that  contain  application- 
specific  data  accessible  via  an  application  layer  protocol.  Each  TmNS  application 
defines  a  set  of  common  resources  and  a  set  of  application-specific  resources.  This 
chapter  provides  details  concerning  the  standardized  application  resources. 

•  IRIG  106  Chapter  26:  TmNSDataMessage  Transfer  Protocol 

The  TmNS  has  defined  several  data  transfer  protocols  unique  for  its  use.  This  chapter 
defines  how  TmNS-specific  messages  (TmNSDataMessages)  are  transferred  between 
TmNSApps. 

•  IRIG  106  Chapter  27 :  Radio  Frequency  (RF)  Network  Access  Fayer 

This  chapter  defines  the  standard  for  managing  the  physical  layer  of  RF  links  with  the 
RF  network.  The  network  implements  an  Open  Systems  Interconnection  (OSI)  model 
approach  to  data  transmission,  where  data  moves  through  the  OSI  stack  from  the 


2I-I 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  21,  July  2017 


application  layer  to  the  physical  layer,  from  physical  layer  to  physical  layer  through 
some  transmission  medium,  then  back  up  the  stack  to  another  application  on  the 
receiving  side. 

•  IRIG  106  Chapter  28:  RF  Network  Management 

This  chapter  defines  the  mechanisms  and  processes  for  managing  RF  links  within  the 
RF  network. 

21.2  Telemetry  Network  Standard  Overview 

At  its  core  the  TmNS  describes  networks  and  interfaces  for  components  on  the  networks. 
All  TmNS-based  networks  strive  to  be  similar  to  existing  Internet-based  networks.  Additionally, 
the  TmNS  provides  mechanisms  for  melding  with  pre-existing  devices,  approaches,  and 
technologies. 

A  fundamental  principle  of  the  TmNS  approach  is  to  enhance,  rather  than  replace, 
today’s  telemetry  systems  by  providing  significant  improvements  in  spectrum  efficiency  in  order 
to  revolutionize  how  flight  tests  are  executed.  This  enhancement  principle  in  turn  drives  the 
need  for  the  new  TmNS-based  capabilities  to  be  melded  with  pre-existing  devices,  approaches, 
and  technologies.  As  such,  the  existing  pulse  code  modulation  (PCM)  telemetry  systems  are 
augmented  with  TmNS  features  provided  through  TmNS  components. 

The  IP  network  foundation  of  the  TmNS  brings  with  it  features  including  routing.  Quality 
of  Service  (QoS),  and  congestion  control.  The  following  list  highlights  some  of  the  capabilities 
that  IP  networking  brings  to  telemetry. 

•  Addition  of  Bidirectional  Communications  to  Telemetry:  bidirectional 
communications  is  one  of  the  most  fundamental  enhancements  provided  by  the 
TmNS.  It  enables  the  following  capabilities. 

o  Real-Time  Access  to  Test  Article  (TA)  Measurements:  Provides  a  mechanism  for 
real-time  access  to  current  and  past  measurements  on  the  TA  both  directly  from 
the  sensors  and  from  the  recorder(s). 

o  PCM  Backfill:  Provides  the  ability  to  retrieve  measurements  from  the  TAs  in  near 
real  time  that  were  dropped  in  the  Serial  Streaming  Telemetry  feed  (PCM 
dropouts). 

o  Real-Time  Command  and  Control  of  TA  Equipment:  Provides  the  ability  to 
status,  configure,  and  control  TA  equipment  from  the  ground  station. 

•  Dynamic  Spectrum  Sharing:  Provides  the  ability  to  share  spectrum  resources  among 
many  concurrent  test  activities  based  on  instantaneous  demand  for  telemetry 
resources. 

•  Quality  of  Service:  Provides  the  ability  to  dynamically  share  spectrum  resources 
based  on  priorities  of  certain  activities  over  others  and  also  to  prioritize  the  delivery 
of  certain  measurements  over  others  (e.g.,  voice). 

•  Fully  Interconnected  System:  Provides  the  ability  to  seamlessly  transition 
transmission  and  receipt  of  data  from  TAs  from  one  antenna  to  another,  including 
antennas  in  different  networks  (frequencies)  and  in  other  ranges.  The  TmNS  uses  the 
term  “handoff  ’  to  describe  this  type  of  transition. 
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•  Over-the-Horizon  Telemetry:  Provides  the  ability  to  perform  TA-to-TA  telemetry 
(relay)  communications  to  support  tests  involving  large  numbers  of  TAs  and  long 
distances. 

21.2.1  TmNS  System  Concepts 

The  TmNS  defines  interfaces,  data  delivery  protocols,  configuration  files,  and  command 
and  control  concepts.  These  are  standardized  so  as  to  support  interoperability  across  components 
(and  vendors)  within  a  particular  TmNS-defined  network. 

21.2.1.1  TmNS  Interfaces 

The  TmNS  is  composed  of  sets  of  components  that  are  modeled  after  network  appliances 
typically  found  on  the  Internet.  In  fact,  some  TmNS  system  components  (e.g.,  routers  and 
switches)  are  almost  exact  functional  matches  to  network  appliances  that  are  used  on  the 
Internet.  Each  TmNS-compliant  component  implements  certain  TmNS  interfaces  (as 
applicable),  thus  providing  multi- vendor  interoperability.  These  TmNS  interfaces  are  as  follows. 

•  Management  Interface:  Used  for  configuring,  obtaining  status,  controlling,  and 
reporting.  The  MDL  is  the  main  interface  used  for  configuring  TmNS-compliant 
devices.  Further  details  concerning  this  topic  are  found  in  Chapter  23  and  Chapter 
25. 

•  Time  Interface:  Used  for  distribution  and  acquisition  of  time  through  the  network. 
Further  details  concerning  this  topic  are  found  in  Chapter  22. 

•  Data  (Measurements)  Delivery  Interface:  Used  to  move  acquired  test  data  from  TAs 
to  ground  processing  based  on  different  delivery  requirements.  Further  details 
concerning  this  topic  are  found  in  Chapter  23,  Chapter  24,  and  Chapter  26. 

•  RF  Network  Interface:  Defines  mechanisms  for  low-level  control  and  status  of  the 
two-way  telemetry  communications  and  overall  spectrum  sharing.  Further  details 
concerning  this  topic  are  found  in  Chapter  27  and  Chapter  28. 


NOTE 


Not  all  components  are  required  to  support  all  interfaces.  For  example,  a  data 
acquisition  unit  (DAU)  would  typically  implement  the  management,  time,  and 
data  interfaces  listed  above.  This  architecture  choice  was  made  to  minimize 
the  complexity  of  any  one  item  and  to  aid  the  possibility  of  creating  a  broad 
array  of  configurations. 


21.2.1.2  Data  Delivery 

The  TmNS  defines  two  data  delivery  mechanisms. 

•  Fatency/Throughput  Critical  Delivery  Protocol:  used  to  deliver  test  data  when  latency 
or  throughput  constraints  are  more  important  than  reliability  constraints  (real-time). 
The  underlying  technologies  supporting  this  delivery  protocol  are  User  Datagram 
Protocol,  Internet  Group  Management  Protocol,  and  IP  multicasting. 

•  Reliability  Critical  Delivery  Protocol:  used  to  deliver  test  data  when  reliability 
constraints  are  more  important  than  latency  or  throughput  constraints  (reliable).  The 
underlying  technologies  supporting  this  delivery  protocol  are  TCP  and  Real  Time 
Streaming  Protocol.  Further  details  concerning  this  topic  are  found  in  Chapter  26. 
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NOTE 


Data  delivery  concepts  support  variations  for  latency,  throughput,  and 
reliability.  For  instance,  during  one  phase  of  a  particular  test,  the  test  operators 
may  need  samples  of  a  particular  set  of  measurements  with  as  little  latency  as 
possible  due  to  safety  of  flight  issues,  even  if  it  means  losing  some  samples 
during  telemetry  dropouts.  In  another  phase  of  the  same  test,  the  test  operators 
may  need  a  reliable  transport  of  these  same  measurements  for  analysis  even  if 
it  raises  latency  due  to  resending  data  lost  during  telemetry  dropouts. 


21.2.1.3  Command  and  Control  Planes 

The  TmNS  defines  two  primary  command  and  control  planes. 

•  Test/Mission  Command  and  Control  Plane  (Red  Network):  This  plane  is  focused  on 
command  and  control  associated  with  a  particular  test.  It  is  concerned  with 
measurements,  telemetry  processing,  message/data  formats,  data  recording,  and  TA 
component  configuration  and  status.  This  plane  resides  in  the  red-side  (plain-text) 
portions  of  a  TmNS  system,  which  are  mainly  comprised  of  the  red  network 
components  on  the  TA(s)  and  Mission  Control  Room,  as  shown  in  Figure  21-1.  Red 
Network  components  are  behind  a  Type-1  inline  network  encryptor. 
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Figure  21-1.  Generalized  TmNS  System  Diagram  Showing  Different 

Control  Planes 


•  Range  Infrastructure  Command  and  Control  Plane  (Black  Network):  This  plane  is 
focused  on  command  and  control  associated  with  the  provisioning  of  resources 
needed  for  a  given  test  or  set  of  tests  within  a  range  or  across  multiple  ranges.  It  is 
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concerned  with  spectrum  sharing,  QoS,  establishment  and  management  of  two-way 
telemetry  communications,  and  the  transitioning  of  communications  from  TAs  from  a 
given  ground  antenna  site  to  another  (antenna-to- antenna  handoff).  This  plane  resides 
in  the  black-side  (cypher-text)  portions  of  a  TmNS  system,  which  are  mainly 
comprised  of  the  ground  antenna  sites,  range  operations  center,  and  black  network 
components  on  the  TA(s),  as  shown  in  Figure  21-1.  Further  details  concerning  this 
topic  are  found  in  Chapter  25  and  Chapter  28. 


NOTE^ 

By  separating  the  control  into  two  planes,  areas  of  concern 

r 

may  be  separate  across  range  personnel. 

21.2.2  TmNS  Core  Technologies 

The  TmNS  utilizes  an  IP  network  that  is  based  on  the  success  and  description  of  the 
Internet  Engineering  Task  Force  (IETF)  hourglass  approach,  as  shown  in  Figure  21-2.  The  IP 
layer  is  the  basic  interoperability  between  networked  components.  Figure  21-3  shows  a  TmNS 
specialization  of  the  classic  IETF  IP  hourglass  figure. 
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Further  details  concerning  this  topic  are  found  in  Chapter  22. 

21.2.2.1  Network-Based  Data  Messages 

Test  data  is  delivered  in  TmNSDataMessages,  which  contain  a  header  and  a  payload. 
Actual  measurements  are  contained  in  the  packages  within  a  TmNSDataMessage,  and  the 
mapping  of  measurements  in  a  TmNSDataMessage  is  defined  in  a  system  configuration  file, 
which  is  an  MDE  file  that  describes  the  configuration  for  a  particular  device  that  is  transmitting 
or  consuming  a  given  TmNSDataMessage.  Further  details  concerning  this  topic  are  found  in 
Chapter  23  and  Chapter  24. 
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21 .2.2.2  System  Configuration  and  Management 

System  management  within  the  TmNS  is  based  upon  the  International  Organization  for 
Standardization  Telecommunications  Management  Network  model  FCAPS,  which  stands  for 
fault,  configuration,  accounting,  performance,  and  security. 

System  management  is  used  across  a  TmNS  system  to  manage  TmNS -compliant 
components,  providing  a  view  of  fault,  configuration,  accounting,  performance,  and  security 
configuration  information  on  the  network.  Essentially,  a  TmNS  system  is  composed  of  two 
types  of  components  when  it  comes  to  management  and  configuration: 

1 .  Managed  devices:  Any  TmNS-compliant  component  that  provides  a  management 
interface  as  defined  by  Chapter  25 ; 

2.  TmNS  Managers:  An  entity  that  manages  TmNS-compliant  components.  Managers 
implement  the  interfaces  necessary  to  manage  TmNS-compliant  components  in 
accordance  with  Chapter  25.  Further  details  concerning  this  topic  are  found  in  Chapter 

Figure  21-4  shows  the  building  blocks  of  system  management  as  specified  by  the  TmNS. 
The  core  technologies  used  are  Simple  Network  Management  Protocol  (SNMP)  to  pass 
management  information  through  the  system.  The  SNMP  management  information  bases 
(MIBs)  provide  dictionaries  for  management  information.  Managed  devices  execute 
applications  called  agents  that  use  the  TmNS-defined  MIB  to  provide  their  internal  status  and  to 
accept  controls  and  configuration.  File  Transfer  Protocol  (FTP),  Hypertext  Transfer  Protocol 
(HTTP),  and  Internet  Control  Message  Protocol  (ping)  play  supporting  roles  related  to  file 
transfer,  discovery,  and  configuration. 
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Further  details  concerning  this  topic  are  found  in  Chapter  22. 
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The  MDL  is  used  for  describing  system  configuration  (Metadata)  in  a  common  fashion. 
The  extensible  Markup  Language  (XML)  schema  defined  by  the  TmNS  provides  the  means  for 
describing  the  configuration  of  the  components  in  a  TmNS  system  as  well  as  their  logical  and 
physical  interrelationships.  The  MDL  is  expressive  enough  to  describe  a  wide  variety  of 
systems:  large  and  small,  simple  and  complex,  from  the  low-level  transducer-to-measurement 
association  for  an  acquisition  card  on  a  DAU  up  to  network  topology  of  multiple  test  mission 
networks. 

A  table  containing  a  mapping  of  MDL  elements  to  relevant  paragraphs  of  the  TmNS 
(IRIG  106  Chapters  21-28)  is  contained  in  Chapter  23  Appendix  23-B.  This  table  can  be  used  by 
a  reader  of  the  standard  to  identify  the  MDL  elements  that  correspond  to  particular  paragraphs  or 
to  identify  the  paragraphs  that  correspond  to  particular  MDL  elements. 

Further  details  concerning  this  topic  are  found  in  Chapter  23. 


By  using  the  system  management  capabilities,  TmNS -compliant  components  can  be 
configured,  reconfigured,  controlled,  and  statused  in  an  interoperable  way. 


NOT^^ 

A  typical  way  to  utilize  the  system  management  capabilities  is  to  provide  a 
system  manager.  This  kind  of  user  application  provides  monitoring, 
controlling,  configuring,  coordinating,  and  visualizing  the  operations  of  a 
system  built  based  on  the  TmNS.  System  manager  users  are  typically  able  to 
obtain  system  and  device-level  status,  including  status  of  TA  instrumentation 
and  information  about  local  and  system- wide  network  performance  (expected 
versus  actual).  Additionally,  the  display  of  a  system  manager  typically 
provides  an  indication  of  system  health  and  details  of  any  fault  conditions 
detected  within  the  TmNS  system. 

21.2.2.3  Time 

Time  within  an  entire  TmNS-based  system  is  distributed  using  IEEE  1588-2008  \  also 
known  as  Precision  Time  Protocol  Version  2.  Time  within  a  TmNS  system  is  delivered  without 
the  addition  of  any  wires. 

Eurther  details  concerning  this  topic  are  found  in  Chapter  22. 

NOT^^ 

All  TmNS-compliant  network  switches  can  be  synchronized  to  an  external  time 
source  (e.g..  Global  Positioning  System)  and  act  as  1588  master  clocks  for  a 
local  network  within  the  TmNS  network  (e.g.,  red  TA  network,  black  TA 
network,  etc.). 

Components  requiring  sub-microsecond  precision,  such  as  DAUs  for  time 
stamping  measurements,  are  able  to  do  so  using  a  hardware  implementation  of 
1588. 

'  Institute  of  Electrical  and  Electronics  Engineers.  IEEE  Standard  for  a  Precision  Clock  Synchronization  Protocol 
for  Networked  Measurement  and  Control  Systems.  IEEE  1588-2008.  Geneva;  International  Electrotechnical 
Commission,  2008. 
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21.2.2.4  Quality  of  Service 

The  TmNS  annotates  a  typical  Differentiated  Services  architecture,  which  is  a  standard  IP 
QoS  mechanism  for  coordination  of  the  delivery  of  competing  data  and  command  and  control 
network  traffic. 


Further  details  concerning  this  topic  are  found  in  Chapter  22  and  Chapter  23. 


The  QoS  mechanism  can  be  used  to  for  certain  sets  of  data  within  a 
particular  test  (or  across  multiple  tests)  that  might  have  stringent  delivery 
requirements  due  to  performance  reasons  (e.g.,  voice  data),  safety  of 
flight  concerns,  etc. 


21.2.2.5  Routing 

Routing  is  the  process  of  selecting  best  paths  in  a  network.  The  TmNS  annotates  IETF 
standards  concerning  a  typical  routed  IP  network.  Using  the  classic  routed  IP  architecture 
enables  a  variety  of  advanced  capabilities,  including  relay,  and  other  capabilities  that  have  not 
yet  been  explored. 


Further  details  concerning  this  topic  are  found  in  Chapter  22  and  Chapter  23. 


Just  as  in  large-scale  networks  (e.g.,  the  Internet)  the  components  within  a 
TmNS-based  network  are  not  aware  about  the  network  path  that  is  used  to 
deliver  data  from  one  node  to  another.  All  a  given  component  needs  to  know 
is  its  next  hop.  This  means  that  components  that  transport  data  within  the 
TmNS  system  need  to  support  these  classic  routing  concepts,  including 
TmNS-compliant  radios,  which  are  network  routers  themselves.  As  such, 
radios  in  general  can  route  data  to  any  other  radio  within  reach  at  any  time. 


21.2.2.6  Source  Selection 

When  RF  propagation  from  one  TmNS-compliant  transmitting  radio  source  arrives  at  two 
or  more  TmNS-compliant  receiving  radios,  it  is  possible  using  routing  and  source  selection  to 
choose  any  one  of  the  network  packets.  This  support  is  provided  through  TmNS  interfaces,  data 
message  formats,  and  management  concepts.  Collectively,  these  concepts  are  called  TmNS 
Source  Selector. 

Further  details  concerning  this  topic  are  found  in  Chapter  28. 

21.2.2.7  Security 

The  TmNS  is  architected  with  a  variety  of  security  mechanisms  in  order  to  meet  a 
particular  program’s  needs.  The  TmNS  security  mechanisms  are  segmented  into  mechanisms 
that  secure  the  data  transfer  from  the  TAs  to  the  ground  (i.e.,  from  one  secure  enclave  to 
another),  as  well  as  for  securing  other  types  of  communications  where  the  information  is  not 
classified,  but  can  be  sensitive  from  an  operational  perspective. 

Communications  between  secure  enclaves  (e.g.,  TAs  and  mission  control)  are  protected 
via  National  Security  Agency-approved  type-1  security  mechanisms  that  mitigate  the  anticipated 
threats.  The  RF  communications  are  protected  via  FIPS- 140-2  mechanisms. 
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Additional  security  mechanisms  used  to  protect  data  within  a  TmNS  system  include: 

•  Secure  Sockets  Layer  (SSL):  used  as  a  security  mechanism  for  transferring  data  over 
HTTP  and  FTP. 

•  SNMP  v3:  needed  for  secure  SNMP  communications  within  a  TmNS  system.  It 
supports  both  authentication  and  privacy. 

Further  details  concerning  this  topic  are  found  in  Chapter  22. 

21.2.2.8  Layered  Architecture  and  Summary  of  Core  Technologies 

The  TmNS  architecture  is,  by  design,  a  communications  and  data  delivery  system  that  is 
partitioned  into  abstraction  layers.  As  in  the  OSI  model,  a  layer  serves  the  layer  above  it  and  is 
served  by  the  layer  below  it.  The  layers  are  in  general  independent,  so  that  a  layer  can  be 
changed  with  little  to  no  impact  to  the  other  layers.  This  layered  architecture  in  turn  allows 
different  technologies  to  be  used  in  each  layer. 

Figure  21-2  and  Figure  21-3  show  the  IETF  hourglass  approach  and  the  corresponding 
specialization  of  that  hourglass.  Figure  21-5  depicts  the  technologies  discussed  in  this  section 
and  how  they  relate  to  each  other  and  work  cohesively  across  the  different  TCP/IP  model  layers. 
Further  details  concerning  this  topic  are  found  in  Chapter  22. 


Figure  21-5.  Core  TmNS  Technologies  and  TmNS-Specific  Protocols  in 

the  TCP/IP  Model  Context 


21.2.3  TmNS  Definitions 

The  TmNS  utilizes  a  collection  of  terms  that  have  specific  meanings  when  used  in  a 
TmNS  context.  They  are  typically  highlighted  in  italics.  A  list  of  the  overarching  definitions 
appears  in  this  section. 
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AES  Cryptographic  Algorithm:  This  Advanced  Encryption  Standard  (AES)  block  cipher 
encryption  algorithm,  described  in  detail  in  EIPS  PUB  197^,  is  recommended  by  the 
National  Security  Agency  in  order  to  provide  an  adequate  protection  mechanism  for  the 
communication  link. 

Agent:  A  Simple  Network  Management  Protocol  (SNMP)  process  that  provides  SNMP-based 
ManagementResources  on  a  NetworkNode  or  NetworkDevice. 

Attached  Synchronization  Marker  (ASM):  A  specific  bit  pattern  preceding  each  low-density 
parity-check  codeblock  group  to  aid  codeblock  frame  synchronization. 

Bit  Error  Rate:  The  ratio  of  the  number  of  bits  incorrectly  received  to  the  total  number  of  bits 
sent  during  a  specific  time  interval. 

Black  (or  Blackside):  A  portion  of  a  network  that  is  not  physically  protected  (not  secure)  with 
respect  to  another  portion  of  the  network.  Sensitive  data  that  traverses  this  network  must 
be  protected  by  encryption. 

Burst:  The  time  interval  of  RE  emission,  from  start  to  end  in  a  time-division  multiplex  media 
access  scheme. 

Burst  Preamble:  A  specific  bit  pattern  transmitted  at  the  beginning  of  a  burst  to  facilitate 
carrier  frequency  symbol  timing  acquisition. 

Burst  Sequence:  The  burst  information  field  structure. 

Burst  Synchronization:  Involves  the  acquisition  and  tracking  of  the  signal  carrier(s),  the 
symbols/bits,  the  frames  or  codeblocks  from  a  recovered  clock  at  the  receiver. 

Carrier  Frequency  Error:  Uplink  and  downlink  frequency  error  bounds  established  for  single¬ 
carrier  SOQPSK-TG  waveform. 

Codeblock:  The  minimum  quanta  of  a  fixed  EDPC  codeword  block  that  consists  of  4,096 
information  bits  or  6144  coded  bits  with  2/3  EDPC  code  rate. 

Codeblock  Frame:  A  variable  PHY  frame  unit  that  consists  of  a  minimum  of  one  EDPC 

codeblock  and  up  to  maximum  of  eight  EDPC  codeblocks.  It  is  preceded  by  an  attached 
synchronization  marker  (ASM). 

DataDeliveryControlChannel:  The  common  elements  of  the  communication  mechanisms  for 
the  setup,  tear-down,  and  operation  of  the  RC  and  LTC  Delivery  Protocols.  See  Chapter 
26. 

DataChannel:  Identifies  a  network  connection  used  to  transport  TmNSDataMessages  between  a 
DataSource  and  a  DataSink. 

DataSink:  A  TmNSApp  that  consumes  TmNSDataMessages  that  contain  MeasurementData. 
Identified  as  the  data-consuming  portion  of  a  ResourceClient  or  ResourceServer. 

DataSource:  A  TmNSApp  that  produces  TmNSDataMessages  that  contain  MeasurementData. 
Identified  as  the  data-producing  portion  of  a  ResourceClient  or  ResourceServer. 


^  National  Institute  of  Standards  and  Technology.  “Specification  for  the  Advanced  Encryption  Standard  (AES).” 
EIPS  PUB  197.  26  November,  2001.  May  be  superseded  by  update.  Available  at 
http://nvlpubs.nist.gov/nistpubs/PIPS/NIST.PIPS.197.pdf. 
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DiffServ  (Differentiated  Services):  A  computer  networking  architecture  that  specifies  a  simple, 
scalable  and  coarse-grained  meehanism  for  classifying,  managing  and  providing  Quality 
of  Service  (QoS)  guarantees  on  IP  network  traffic. 

Downlink  Transmission:  Communication  originating  at  a  Test  Article  and  terminating  at  the 
Ground.  With  reference  to  a  Relay,  communication  originating  at  a  Test  Article  and 
terminating  at  the  Relay. 

Dynamic  Allocation:  A  method  of  scheduling  TDMA  time  slots  for  transmissions  by  radios 
based  on  a  set  of  criteria,  such  as  bandwidth  needs  and  mission  priorities. 

Enclave:  A  distinct  portion  of  a  network,  system  or  facility  that  is  isolated,  usually  for  security- 
related  purposes,  from  the  rest  of  the  network,  system  or  facility. 

Encryption  &  Decryption:  NIST  FIPS  140-2  certified  bulk  cryptographic  module  along  with 
AES  cryptographic  algorithm  is  recommended  by  the  National  Security  Agency  for 
communication  link  security  at  link  layer. 

Epoch:  A  TDMA  frame  unit  that  allocates  transmission  opportunity  (TxOp)  resources  for 
uplink  and  downlink.  Epoch  is  equivalent  to  a  TDMA  frame. 

Forward  Error  Correction:  A  system  of  error  control  for  data  transmission,  whereby  sender 
adds  redundant  data  to  its  messages,  which  is  known  as  error  correction  code.  This 
allows  receiver  to  detect  and  correct  errors  (within  some  bound)  without  the  need  to  ask 
the  sender  for  additional  data. 

Ground  Network:  One  or  more  TmNS  Networks  that  interconneet  Ground-hd&ed 
NetworkNodes. 

Ground  Station  (GS):  A  ground  infrastructure  that,  at  a  minimum,  consists  of  primary  and 
remote  antenna  sites,  serial  streaming  telemetry  (SST)  and  ground  network 
infrastructures.  Nominally  Ground  Radios  are  located  in  a  Ground  Station. 

Ground  Station  Network:  A  TmNS  Network  that  interconnects  connected  NetworkNodes 
physically  residing  in  a  Ground  Station. 

Handoff:  The  process  of  transferring  communications  from  one  source  radio  to  another  source 
radio  for  the  same  destination  RF  MAC  Address.  The  original  source  radio  may  be 
referred  to  as  the  “Leave  Radio”  while  the  new  source  radio  may  be  referred  to  as  the 
“Join  Radio”. 

HDLC  Frame:  A  protocol  based  on  ISO-13239  Standard  that  was  modified  to  support  frame 
boundary  delineations,  to  carry  link  layer  control  messages  and  user  datagrams. 

Information  Data:  The  channel  information  data,  prior  to  channel  coding,  that  includes  user 
data  and  channel  overhead  affiliated  with  OSI  layer- 1  and  layer-2.  Overhead  affiliated 
with  OSI  layer-3  through  layer-7  is  included  as  user  data. 

Integrated  Services  (IntServ):  A  computer  network  architeeture  that  specifies  fine-grained, 
reservation-based  mechanisms  for  providing  Quality  of  Service  (QoS)  guarantees  for 
individual  IP  network  traffic  flows. 

Latency/Throughput  Critical  (ETC)  Delivery  Protocol:  The  TmNS-specific  application-level 
method  of  delivering  TmNSDataMessages  via  User  Datagram  Protocol  (UDP). 
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Link  Agent:  Executes  link  control  operations  in  a  Radio. 

Link  Manager  (LM):  A  TmNSApp  responsible  for  optimized  control  and  coordination  of  Radio 
operations  across  multiple  Radios  in  the  RF  Network.  The  primary  role  of  RF  Fink 
Management  is  implementation  of  the  TDMA  controller  that  allocates  transmission 
opportunities  for  its  managed  Radio  components. 

Low-Density  Parity-Check  (LDPC)  Code  -  A  variant  of  Forward  Error  Correction  codes  that 
uses  block  codes  for  error  correction.  Code  is  specified  by  parity  check  matrix  FI  and 
utilizes  generator  matrix  G  to  perform  encoding. 

LTCControlChannel:  The  communication  mechanism  for  the  setup,  tear-down,  and  operation 
of  the  LTC  Delivery  Protocol.  See  Chapter  26. 

LTCDataChannel:  The  communication  mechanism  for  delivery  of  TmNSDataMessages  using 
the  LTC  Delivery  Protocol.  See  Chapter  26. 

LTCDataSink:  A  DataSink  that  utilizes  the  LTC  Delivery  Protocol. 

LTCDataSource:  A  DataSource  that  utilizes  the  LTC  Delivery  Protocol. 

Management  Information  Base  (MIB):  A  “Structure  of  Management  Information”  (SMI) 
formatted  text  file  used  by  the  SNMP  Agents  and  Managers  to  define  a  common 
communication  language  for  exchanging  management  information. 

ManagementResource:  An  application-accessible  entity  that  is  used  for  command,  control,  and 
health  and  status  monitoring.  ManagementResources  may  be  generic  to  the  host  platform 
or  may  be  specific  to  the  TmNS-based  environment. 

ManagementURI:  The  Uniform  Resource  Identifier  (URI)  that  describes  a  particular 
ManagementResource. 

Manager:  A  Simple  Network  Management  Protocol  (SNMP)  process  that  accesses  SNMP- 
based  ManagementResources  on  a  NetworkNode. 

MeasurementData:  A  digital  representation  of  a  measurement. 

MeasurementID  (MeasID):  A  numerical  identifier  that  refers  to  a  specific  MeasurementData 
described  in  an  MDL  instance  document. 

MessageDefinitionID  (MDID):  A  numerical  identifier  that  refers  to  a  specific  Message 
Definition  described  in  an  MDL  instance  document. 

Metadata:  Information  that  describes  a  system  and  data  interrelationships;  defined  in  the 
Telemetry  Network  Standard. 

Metadata  Description  Language  (MDL)  Instance  Document:  A  document  that  complies  with 
the  language  defined  in  Chapter  23. 

NetworkDevice:  A  NetworkNode  that  provides  network  and/or  data  link  layer  service  and 

interconnectivity,  without  modifying  data  above  the  network  layer.  See  Open  Systems 
Interconnection  (OSI)  model. 

Networkinterface:  A  module  that  implements  an  interface,  both  logical  and  physical,  between 
a  NetworkNode  and  a  TmNS  Network. 
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NetworkNode:  Any  device  that  contains  a  Networkinterface  that  is  connected  to  a  TmNS 
Network.  Nominally  runs  one  or  more  TmNSApps. 

Notification:  An  asynchronous  SNMP  message  generated  by  a  TMA. 

Occupied  Bandwidth  (OBW):  The  bandwidth  containing  99%  of  the  total  integrated  power  of 
the  transmitted  spectrum,  centered  on  the  assigned  channel  frequency.  The  width  of  a 
frequency  band  such  that,  below  the  lower  and  above  the  upper  frequency  limits,  the 
mean  powers  emitted  are  each  equal  to  a  specified  percentage  B/2  of  the  total  mean 
power  of  a  given  emission.  In  this  standard,  B/2  is  taken  as  0.5%. 

Octet:  A  sequence  of  eight  bits. 

Package:  A  data  container  composed  of  MeasurementData. 

PackageDefinitionID  (PDID):  A  numerical  identifier  that  refers  to  a  specific  Package 
Definition  described  in  an  MDL  instance  document. 

Physical  Layer  (PHY):  The  first  and  lowest  layer  in  the  seven-layer  OSI  model.  This  layer 

defines  the  means  of  transmitting  raw  bits  rather  than  logical  data  packets  over  a  physical 
link  connecting  Radio  and  network  nodes.  This  layer  translates  logical  communications 
requests  from  the  data  link  layer  into  hardware-specific  operations  to  effect  transmission 
or  reception  of  electronic  signals. 

Quality  of  Service:  An  umbrella  term  describing  the  delivery  and  performance  requirements  of 
a  data  transfer  and/or  the  network  mechanisms  used  to  meet  those  requirements. 

Queue  Management:  An  RF  Network-defined  common,  standardized  interface  to  the  Traffic 
Engineering  Queues,  which  may  be  implemented  with  non-standard,  vendor-specific 
mechanisms. 

Radio:  Consists  of  a  Link  Agent,  RF  transceiver,  and  Ethernet  transceiver. 

Radio  Air  Channel  Data  Rate:  Raw  channel  data  rate  that  includes  user  data,  aggregated 
overheads  (physical  and  layer-2),  and  coding  overhead. 

Radio  Air  Data  Rate:  Data  rate  from  the  output  of  the  radio  modulator.  Specified  as: 

•  Radio  air  user  data  rate,  prior  to  aggregated  overheads  (physical  and  layer-2)  and  coding. 

•  Radio  air  information  data  rate  that  includes  aggregated  overheads  but  prior  to  coding. 

•  Radio  air  channel  data  rate  that  includes  aggregated  overheads  and  coding 

Radio  Bearer:  The  service  provided  by  the  RF  Network  to  transfer  data  between  the  test  article 
network  and  ground  station  network.  Service  is  the  collection  of  all  means  and  facilities 
provided  by  the  network  to  allow  a  certain  type  of  communication  over  the  network. 

RCControlChannel:  The  communication  mechanism  for  the  setup,  tear-down,  and  operation  of 
the  RC  Delivery  Protocol.  See  Chapter  26. 

RCDataChannel:  The  communication  mechanism  for  delivery  of  TmNSDataMessages  using 
the  RC  Delivery  Protocol.  See  Chapter  26. 

RCDataSink:  A  DataSink  that  utilizes  the  RC  Delivery  Protocol. 

RCDataSource:  A  DataSource  that  utilizes  the  RC  Delivery  Protocol. 
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Red  (or  Redside):  A  portion  of  a  network  that  is  physically  protected  (secure)  with  respect  to 
another  portion  of  the  network.  Sensitive  data  may  be  communicated  within  this 
protected  enclave  without  need  for  encryption. 

Relay:  Hierarchical  TDMA  node  structure  that  allows  Test  Article  to  act  as  a  relay  node  to 

extend  communication  link  ranges  by  facilitating  nearby  Test  Articles  to  join  the  network 
and  by  linking  communications  between  TDMA  controllers. 

Reliability  Critical  (RC)  Delivery  Protocol:  The  TmNS-specific  application-level  method  of 
delivering  TmNSDataMessages  via  Transmission  Control  Protocol  (TCP). 

ResourceChannel:  Identifies  a  network  connection  used  to  transport  ResourceRequests  and 
ResourceResponses  between  a  ResourceClient  and  a  ResourceServer. 

ResourceClient:  A  TmNSApp  that  generates  ResourceRequests  and  may  incorporate  the 
DataSource  and/or  DataSink  functionality. 

Resourceinterface:  A  software  interface  used  by  TMAs  to  access  ManagementResources .  The 
standard  currently  supports  an  SNMP-based  interface  and  an  HTTP -based  interface  for 
accessing  different  ManagementResources. 

ResourceRequest:  Request  to  access  a  specific  ManagementResource  and  is  generated  by  a 
ResourceClient. 

ResourceResponse:  Returns  information  in  response  to  a  ResourceRequest  regarding  a  specific 
ManagementResource  and  is  generated  by  a  ResourceServer. 

ResourceServer:  A  TMA  that  receives  and  processes  ResourceRequests,  generates 

ResourceResponses,  and  may  incorporate  the  DataSource  and/or  DataSink  functionality. 

RF  Network:  The  segment  of  a  TmNS  Network  that  provides  network  connectivity  over  RF 
interfaces  between  Test  Article  Networks  and  Ground  Station  Networks. 

RF  Network  Message  (RFNM):  A  network-independent  structure  that  contains  control  or 
status  information  regarding  RF  Network  conditions. 

RolelD:  A  string  that  refers  to  the  role  of  a  TMA. 

SOQPSK-TG  Waveform:  An  RCC-TG-defined  variant  of  MIL-STD-188/181A  ternary 

continuous  phase  modulated  single-carrier  waveform  established  to  achieve  spectrum 
efficiency  and  robustness. 

Spectral  Mask:  Requirement  for  RF  emission  spectrum  containment  for  single-carrier 
SOQPSK-TG  waveform. 

Telemetry  Network  Standard  (TmNS):  Another  name  for  IRIG  106  Chapters  21-28. 

Test  Article:  A  vehicle  infrastructure  that,  at  a  minimum,  consists  of  on-board  antenna.  Serial 
Streaming  Telemetry  (SST)  and  test  article  network  infrastructures. 

Test  Article  Network:  A  TmNS  Network  that  interconnects  connected  NetworkNodes  physically 
residing  on  a  test  article. 

Time  Division  Multiple  Access  (TDMA):  A  Time-Division  Duplex  scheme  (TDD)  to  separate 
uplink  and  downlink  transmission  signals.  TDMA  emulates  full-duplex  communication 
over  a  half-duplex  link. 
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TmNS Application  (TmNSApp):  an  application  running  on  a  NetworkNode  that  provides  or 
utilizes  one  or  more  TmNS  interfaces. 

TmNSManageableApplication  (TMA):  A  TmNSApp  that  provides  other  applications  with 
access  to  a  set  of  ManagementResources  via  one  or  more  Resourceinterfaces . 

TmNSAppManager:  An  application  that  monitors  the  status  or  controls  one  or  more  TMAs. 

TmNSDataMessage:  An  MDID-based  TmNSMessage  that  contains  a 

TmNSDataMessageHeader  and  a  TmNSDataMessagePayload;  described  in  Chapter  24. 

TmNSDataMessageHeader:  Fields  in  a  TmNSDataMessage  that  precede  a 
TmNSDataMessagePayload. 

TmNSDataMessagePayload:  Composed  of  zero  or  more  Packages. 

TmNSMessage:  A  network-independent  structure  composed  of  a  TmNSMessageHeader  and  a 
TmNSMessagePayload\  described  in  Chapter  24. 

TmNStimestamp:  A  TmNS-specific  time  format  for  encoding  timestamps  in  a  human-readable 
textual  representation  (yyyymmddThhmmss.sssssssss). 

TmNS  Network:  A  network  that  conforms  to  the  IRIG  106  Chapter  21-28  Telemetry  Network 
Standard. 

TmNS  Source  Selector  (TSS):  Tunnel  management  functionality 

T  mN  S_Request_Def ined_URI :  The  uniform  resource  identifier  (URI)  that  describes  the 
request  specification  as  defined  by  the  LTC  and  RC  Delivery  Protocols. 

Traffic  Engineering  Queues  (TE  Queues):  A  set  of  functionality  provided  by  the  RF  Network 
that  collectively  includes  the  implementation  and  control  of  queue  structures  and 
associated  mechanisms  used  to  provide  optimized  Quality  of  Service  performance. 

Transmission  Opportunity  (TxOp):  Transmission  time  slots  assigned  by  a  TDMA  controller 
to  each  Test  Article  Radio  for  downlink  transmission  of  data  and  control  information  and 
to  the  Ground  Station  Radio  for  uplink  transmission  of  data  and  control  information. 

TSS  Client:  An  application  that  implements  one  or  more  TSS  Interfaces  and  issues  tunnel 
connection  commands  to  a  TSS  Server. 

TSS  Server:  An  application  that  implements  a  TSS  Interface  and  listens  for  incoming  tunnel 
connection  commands  from  TSS  Clients. 

Type  Length  Value  (TLV):  A  flexible  format  for  defining  or  specifying  data  fields  in  a 

message,  especially  when  the  fields  may  be  of  variable  length  and  multiple  fields  are 
encapsulated  into  the  message.  Used  as  the  data  structure  that  forms  RFNMs. 

Uplink  Transmission:  Communication  originating  at  the  Ground  and  terminating  at  a  Test 
Article.  With  reference  to  a  Relay,  communication  originating  at  the  Relay  and 
terminating  at  a  Test  Article. 

User  Data:  Referred  to  as  test  data,  mission  data,  or  data  plane  data. 

21.3  Relationship  Between  Standards  and  Specifications 
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As  part  of  the  integrated  Network  Enhanced  Telemetry  (iNET)  program,  the  TmNS  and 
specifications  were  developed  to  guide  the  development  of  the  system  and  the  interoperability 
between  the  components.  The  goal  of  the  TmNS  is  to  promote  an  open  system  architecture  and 
interoperability  across  component  vendors  by  defining  functional  system  interfaces.  The  intent 
of  the  specifications  is  to  define  the  system,  hardware,  software,  testing,  and  performance 
requirements  associated  with  the  TmNS  Demonstration  System  and  each  of  the  components 
within  the  TmNS  Demonstration  System.  As  such,  the  requirements  contained  in  each 
component  specification  largely  reference  back  to  the  TmNS.  It  is  important  to  note  that  the 
specifications  were  developed  in  preparation  for  the  TmNS  Demonstration  System  and,  while 
they  are  suited  for  other  systems  implementing  the  TmNS,  a  range  may  decide  to  tailor  these 
specifications  to  meet  their  specific  needs. 
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APPENDIX  21-A 
Clarifications  and  Conventions 
A.l.  Standards  Key  Words 

In  many  sections  of  Chapters  21-28,  key  words  are  used  to  signify  the  requirements  in  the 
standard.  This  section  defines  these  words  (derived  from  Request  for  Comment  [RFC]  21 19^)  as 
they  should  be  interpreted  in  iNET  standards.  Note  that  the  force  of  these  words  is  modified  by 
the  requirement  level  of  the  standard  in  which  they  are  used. 

•  SHALL:  This  word  means  that  the  definition  is  an  absolute  requirement  of  the  standard. 

•  SHALL  NOT:  This  phrase  means  that  the  definition  is  an  absolute  prohibition  of  the 
standard. 

•  SHOULD:  This  word  means  that  there  may  exist  valid  reasons  in  particular  circumstances  to 
ignore  a  particular  item,  but  the  full  implications  must  be  understood  and  carefully  weighed 
before  choosing  a  different  course. 

•  SHOULD  NOT:  This  phrase  means  that  there  may  exist  valid  reasons  in  particular 
circumstances  when  the  particular  behavior  is  acceptable  or  even  useful,  but  the  full 
implications  should  be  understood  and  the  case  carefully  weighed  before  implementing  any 
behavior  described  with  this  label. 

•  MAY :  This  word  means  that  an  item  is  truly  optional.  One  implementation  may  choose  to 
include  the  item  because  a  particular  marketplace  requires  it  or  because  the  implementation 
enhances  the  product  while  another  implementation  may  omit  the  same  item.  An 
implementation  that  does  not  include  a  particular  option  SHALL  be  prepared  to  interoperate 
with  another  implementation  that  does  include  the  option,  though  perhaps  with  reduced 
functionality.  In  the  same  vein,  an  implementation  that  does  include  a  particular  option 
SHALL  be  prepared  to  interoperate  with  another  implementation  that  does  not  include  the 
option  (except,  of  course,  for  the  feature  the  option  provides). 

A.2.  Document  Conventions 

A. 2. a.  Usage  of  Defined  Terms 

The  words  defined  in  Subsection  21.2.3  are  reserved  for  specific  use  and  will  be  italicized 
when  they  appear  throughout  the  TmNS  chapters.  The  use  of  italics  is  reserved  exclusively  for 
words  that  appear  in  Subsection  21.2.3. 

A.2.b.  Usage  of  Message  Fields 

Names  of  specific  fields  within  the  TmNSDataMessage  structure  are  indicated  by  an  Arial 
font.  Some  field  names  are  the  same  as  terms  defined  in  Subsection  21.2.3.  When  a  statement 
refers  to  a  field,  the  field  name  will  adhere  to  this  convention.  It  will  not  be  italicized. 


^  Internet  Engineering  Task  Force.  “Key  Words  for  Use  in  RFCs  to  Indicate  Requirement  Level.”  RFC  21 19. 
March  1997.  May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc21 19/. 
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A.2.C.  Scope  of  References 

A  reference  to  a  section  number  from  any  of  the  TmNS  ehapters  includes  only  that 
specific  section  and  not  its  subsections.  A  reference  to  a  section  number  followed  by  an  asterisk 
indieates  that  the  seetion  refereneed  and  all  of  its  subseetions  are  ineluded  in  the  eontext  of  the 
referenee. 

A.2.d.  Usage  of  Note  Boxes 

Throughout  the  TmNS  ehapters,  note  boxes  such  as  the  one  below  will  appear  with 
information  relevant  to  the  material  being  presented  in  the  surrounding  text.  These  note  boxes 
will  act  as  a  supplement  to  guide  the  reader  with  rationale  and  advisories  where  they  are  deemed 
useful;  however,  the  eontent  of  the  note  boxes  is  purely  informational.  Either  by  their  presenee 
and/or  removal,  the  note  boxes  shall  not  augment  the  rules  and  specifieations  presented  in  the 
TmNS  in  any  way. 

This  is  an  example  of  a  note  box  that  appears  in  the  TmNS. 


A.3.  SNMP  Conventions 

This  document  uses  a  set  of  conventions  when  defining  SNMP  variables. 

•  For  each  variable,  a  “Type”  and  a  “Read-Write”  value  is  indieated.  These  values  are 
defined  by  the  SNMP  RFCs  and  are  only  restated  here  for  clarity. 

o  Type  (of  SNMP  variables)  -  NOTIFICATION-TYPE,  IpAddress,  Counter64, 
Counter32,  Integer32,  Unsigned32,  and  TimeTicks  are  defined  by  SNMPv2-SMI 
(RFC  2578“^).  TestAndIner,  TruthValue,  and  DisplayString  are  defined  by 
SNMPv2-TC  (RFC  2579^).  INTEGER  is  an  enumerated  form  of  Integer32. 
o  Read-Write  (of  SNMP  variable)  -  read-only,  read-write,  read-create,  not- 
aeeessible,  and  aeeessible-for-notify  are  SNMP  variable  aeeess  levels  (RFC 
2578).  The  first  two  types  are  self-explanatory.  The  term  “read-create”  indicates 
a  table  entry  may  be  read,  created,  or  modified.  The  term  “not-accessible”  means 
the  variable  is  used  internally  by  the  SNMP  Agent  (sueh  as  a  table  index),  but  is 
not  retrievable  through  SNMP  network  eommands.  The  term  “aeeessible-for- 
notify”  means  the  variable  is  used  as  part  of  an  SNMP  notification  and  is  not 
retrievable  through  SNMP  network  eommands. 

•  To  define  the  structure  of  the  SNMP  MIB  tree,  the  following  convention  is  used: 

o  [Braeketed  Deseription]  -  Deseription  entries  in  variable  tables  surrounded  with 
square  braekets  indieate  the  variable’s  plaeement  in  the  TmNS  MIB.  For  example: 
[tmnsTmaCommonIdentification  2]  indicates  that  the  variable  is  the  seeond 
variable  on  the  tmnsTmaCommonIdentification  branch. 


Internet  Engineering  Task  Force.  “Structure  of  Management  Information  Version  2  (SMIv2).”  April  1999.  May 
be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
httt)s://datatracker.ietf.org/doc/rfc2578/. 

^  Internet  Engineering  Task  Force.  “Textual  Conventions  for  SMIv2.”  RFC  2579.  April  1999.  May  be  superseded 
or  amended  by  update.  Retrieved  18  April  2017.  Available  at  https ://datatracker. ietf  org/doc/rfc2579/. 
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•  Conventions  used  in  place  of  table  values  include: 

o  Blank  String  (“”)  -  A  blank  or  empty  string  is  indicated  as  double-quotes  with  no 
characters.  This  is  commonly  used  to  initialize  a  string  before  a  value  is  assigned, 
o  N/A  -  Not  Applicable.  For  example,  this  value  is  given  for  the  default  state  of 
tables  indicating  that  the  table  has  no  rows,  and  so  has  no  default  values.  N/A  is 
also  given  for  read-only  variables  that  are  expected  to  hold  constant  properties  of 
the  device  (such  as  the  TmNSManageable Application  type). 

A.4.  XML  Concepts  and  Style  Guide 

A.4.a.  Standards  Language 

The  Metadata  Standard  defines  a  language.  When  compared  to  the  other  standards,  the 
Metadata  concept  is  closest  to  the  MIB  in  the  System  Management  standard.  Both  define  a 
standard  vocabulary  for  exchanging  information.  The  MIB  variables  are  somewhat  like 
individual  attributes  and  elements  in  a  schema.  A  full  language  differs  from  a  vocabulary  in  that 
in  addition  to  identifying  words  and  meanings,  it  also  defines  how  the  words  can  be  composed 
together  to  form  more-complex  sentences.  These  concepts  together  are  syntax,  which  identifies 
the  words  and  valid  sentence  structures  for  a  language.  The  semantics  of  a  language  are  not 
merely  related  to  the  structure  of  the  sentences,  but  also  construct  the  meanings  of  the  sentences 
in  the  context  of  the  way  the  language  will  be  used. 

The  Metadata  Standard  defines  a  language;  the  syntax  identifies  vocabulary  and  sentence 
structure,  and  the  semantics  provide  meaning.  The  constraints  in  the  Metadata  Standard  are 
distributed  between  statements  that  are  syntax-related  (encoded  and  enforced  by  the  schema)  and 
statements  that  are  semantic-related  (additional  rules  that  are  levied  and  provide  meaning).  The 
syntax  of  the  language  will  be  enforced  using  XML  Schema  constraints.  When  possible,  XML 
mechanisms  are  used  to  enforce  semantic  constraints.  In  cases  not  supported  cleanly  by  XML, 
text  has  been  added  directly  to  this  standard.  In  such  cases,  the  text  will  typically  include  the 
keyword  “shall”.  The  phrase  “the  value  of  the  Name  element  of  the  Measurement  element  shall 
be  unique”  is  one  such  example. 

Metadata  instances  (i.e.,  sentences)  in  general  describe  a  telemetry  system.  The 
descriptions  may  be  used  in  various  ways:  to  configure  NetworkNodes',  to  predict  the 
performance  of  the  network;  or  to  capture  requirements  for  the  telemetry  system. 

A.4.b.  General  MDL  Requirements 

The  MDL  is  an  XML-based  language  for  describing  network-based  telemetry  systems.  It 
can  be  used  to  capture  requirements,  design  decisions,  and  configuration  information.  The  MDL 
can  also  facilitate  the  interchange  of  information  between  tools. 

This  section  provides  context  for  how  to  interpret  the  language  described  herein,  and 
suggests  how  it  can  be  used.  This  includes: 

•  The  drivers  of  the  MDL  design; 

•  The  standards  upon  which  it  is  built; 

•  How  to  extend  and  constrain  the  language. 
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A.4.C.  XML  Schema  Concepts 

The  MDL  defines  a  syntax,  which  includes  a  vocabulary,  a  set  of  types,  and  the  rules  for 
how  an  MDL  instance  document  shall  be  structured.  The  syntax  definition  is  realized  using  the 
XML  Schema  standard,  which  is  maintained  by  the  World  Wide  Web  Consortium.  This  section 
explains  the  basic  concepts  of  XML  Schema  that  are  utilized  by  the  MDL.  A  more-detailed 
explanation  of  the  fundamentals  of  the  XML  Schema  standard  is  outside  the  scope  of  this 
document,  but  an  explanation  can  be  found  in  Section  2.2.2®  of  the  W3C  reference. 

An  XML  Schema  defines  the  rules  of  an  XML-based  language  with  six  main  constructs: 
elements,  attributes,  complex  types,  simple  types,  a  root  element,  and  constraints. 

The  XML  Schema  elements,  of  type  xsd :  element,  represent  information  containers  in 
an  XML  instance  document.  An  element  defines  an  XML  tag  that  appears  as 
“<xsd :  element>”  in  an  instance  document.  This  specification  defines  where  an  element  of  the 
indicated  type  can  be  created  in  the  instance  document. 

The  XML  Schema  attributes,  of  type  xsd:  attribute,  represent  information  that 
describe  the  element  to  which  they  are  attached.  The  MDL  has  very  few  attributes  defined 
because  they  are  reserved  for  XML-specific  uses.  For  example,  they  are  used  when  the  XML 
instance  document  needs  to  have  information  about  the  ordering  of  an  element. 

The  XML  Schema  complex  types,  of  type  xsd:  complexType,  define  structures  that 
specify  what  an  element  can  contain.  Complex  types  are  analogous  to  classes  in  an  object- 
oriented  language.  An  element  defined  as  a  complex  type  can  contain  other  elements  as  well  as 
attributes.  They  can  define  the  combinations  and  ordering  of  the  contained  elements. 

The  XML  Schema  simple  types,  of  type  xsd :  simpleType,  define  restrictions  or 
specializations  of  basic  types  used  within  the  schema  definition.  For  instance,  a  simple  type 
could  be  defined  to  restrict  the  value  of  an  integer,  of  type  xsd:  integer,  to  an  inclusive  range 
of  integer  values  from  0  to  255.  These  constructs  are  used  mainly  for  validation  and  type 
restriction. 

An  XML  Schema  requires  an  instance  document  to  have  a  top-level  element  called  a  root 
element.  The  root  element  contains  all  other  elements  and  attributes  in  an  instance  document. 

The  XML  Schema  constraint  mechanism  defines  a  syntax  (or  grammar)  of  an  XML 
language.  Constraints  enforce  language  rules  against  an  XML  instance  document.  For  example, 
constraints  can  verify  that  referential  integrity  is  maintained. 

The  XML  Schema  constraints  can  also  be  used  to  enforce  semantic  constraints  in  a  very 
limited  way.  For  example,  constraints  can  be  used  to  require  an  element  to  appear  only  if 
another  element  is  defined;  however,  the  XML  Schema  language  does  not  have  the  ability  to 
fully  define  the  semantic  context  that  is  necessary  to  understand  the  full  meaning  of  a  language. 
An  efficient  and  accepted  approach  for  describing  the  semantics  or  meanings  of  a  language  has 
yet  to  be  developed. 


®  World  Wide  Web  Consortium.  “Declaration  Components”  in  XML  Schema  Part  1:  Structures  Second  Edition.  28 
October  2004.  May  be  superseded  by  update.  Retrieved  10  May  2017.  Available  at 
http://www.vv'3.org/TR/xmlschema-l/#Declarations  Summary. 
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A.4.d.  Syntax  Conventions  of  MDL  Element  Descriptions 

Non-literal  symbols  (the  ones  that  are  not  in  “”)  represent  MDL  elements  or  attributes. 
Each  of  these  is  linked  to  a  section  in  this  document. 

By  convention,  this  standard  includes  the  built-in  XML  Schema  types,  which  are 
identified  with  the  namespace  prefix  “xsd”.  For  example,  the  Name  element  in  the  example 
above  is  of  the  type  xsd :  string.  The  supported  simple  types  in  the  MDL  are  those  defined  in 
the  XML  Schema  standard.  Simple  data  types  (i.e.,  xsd ;  simpleType  ( s ) )  defined  by  the 
MDL  generally  appear  with  the  namespace  prefix  “mdl”. 

A.4.e.  Conditional  Element  in  the  MDL  Schema  Definition  File 

The  MDL  schema  is  a  system-level  description.  Not  all  components  require  every 
element  to  properly  configure.  In  such  cases,  these  elements  are  conditional.  The 
documentation  specifies  when  the  conditional  elements  shall  be  present  and  processed. 
Components  not  specifically  called  out  in  documentation  of  conditional  elements  shall  not  fail  to 
configure  if  the  particular  conditional  element  is  not  present. 

A.4.f.  Naming  Conventions  in  the  MDL  Schema  Definition  File 

The  Metadata  Standard  details  the  elements  and  attributes  that  form  the  MDL  schema.  In 
the  MDL  schema  definition  file,  these  MDL  elements  and  attributes  appear  as  instances  of 
defined  xsd:  complexType  and  xsd:  simpleType  elements.  Each  declaration  of  these  MDL- 
specific  elements  will  specify  a  name  attribute  that  is  assigned  a  string  that  contains  the  name  of 
the  MDL  element  being  described  followed  by  a  string  suffix  of  “Type”  or  “Enum”.  For 
example,  the  top-level  element  of  the  MDL  schema  is  the  MDLRoot  element.  In  the  MDL 
schema  definition  file,  this  element  appears  as  an  instance  of  an  xsd:  complexType  element 
with  a  name  attribute  of  “MDLRootType”.  These  name  attribute  strings  that  correspond  to  the 
defined  MDL  elements  do  not  appear  in  this  document;  they  only  appear  in  the  MDL  schema 
definition  file. 

A.4.g.  Indexing  Policies 

Numerical  indices  present  in  an  MDL  instance  document  are  recommended  to  count 
starting  at  1  and  to  increment  by  one  (i.e.,  1,  2,  3,  4,...). 

A.4.h.  Use  of  Supplemental  XML-Based  Standards 

The  use  of  other  XML-based  standards  (i.e.,  other  schemas)  in  conjunction  with  the  MDL 
schema  is  permitted.  Potentially,  the  use  of  these  external  standards  through  their  accompanying 
schemas  leverages  existing  knowledge  to  describe  concepts  and  domains  beyond  those  in  the 
MDL.  The  MDL  does  not  explicitly  constrain  the  available  mechanisms  to  use  external 
standards;  however,  the  linking  of  external  schemas  to  the  MDL  schema  shall  not  result  in  the 
modification  of  the  MDL  schema. 

Refer  to  Chapter  23  Appendix  23-A  for  example  approaches  and  mechanisms  for  linking 
other  XML-based  schemas  to  the  MDL  schema. 
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A.4.i.  Uniqueness  of  ID  Attributes 

Values  of  ID  attributes  of  any  element  in  an  MDL  instance  document  shall  be  unique. 
The  ID  attributes  are  used  to  implement  references. 

A.4.j.  Description  of  ReadOnly  Element 

All  elements  of  type  xsd :  complexType  in  the  MDL  schema  contain  an  optional 
Readonly  element,  which,  of  type  xsd:  boolean,  indicates  whether  or  not  its  containing 
element  and  all  its  subelements  can  be  modified.  A  value  of  “true”  indicates  that  these  elements 
cannot  be  modified.  Conversely,  a  value  of  “false”  indicates  that  these  elements  can  be 
modified.  The  default  value  of  the  Readonly  element  is  “false”. 

A.4.k.  Description  of  Owner  Element 

All  elements  of  type  xsd :  complexType  in  the  MDL  schema  contain  an  optional  Owner 
element,  which  can  occur,  at  most,  once  in  its  containing  element.  The  Owner  element,  of  type 
xsd:  string,  is  an  identifier  for  the  owner  or  administrator  of  the  containing  element  in  an 
MDL  instance  document.  The  rights  and  access  controls  associated  with  the  identified  owner 
will  determine  the  ability  of  MDL  instance  document  editors  to  modify  the  containing  element 
and  all  its  subelements. 


NOTE^ 

It  is  expected  that  a  standardized  set  of  values  for  the  Owner 

element  will  be  established.  Until  these  values  are  determined,  the 

Metadata  Standard  does  not  constrain  the  value  of  the  Owner 

element. 
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APPENDIX  21-B 
Bit  Numbering  and  Byte  Ordering 


B.l.  Bit  Field  Syntax 

Numeric  values  specified  in  bit  fields  shall  be  represented  using  the  following  syntax: 
size  '  radix  value 

where 


size  The  number  of  binary  bits  that  comprise  the  number. 
'  A  single  quote  separator, 

radix  Radix  of  the  number.  Valid  radix  are: 
b  =  binary 
h  =  hexadecimal 
d  =  decimal 

value  Bit  field  value  represented  as  a  numeric  string. 

Examples: 

3'blOl 

32'hl2345678 


20'hlC 

(20'h0001C) 

11 'dl23 

(ll'bOOOOllllOll) 

NOTE^ 

This  bit  field  syntax  is  a  subset  of  the  Verilog  Hardware 

r 

Description  Language  syntax  for  representing  numbers. 

B.2.  Bit  Numbering  Convention 

Whenever  an  octet  field  represents  a  numeric  quantity,  the  left-most  bit  in  the  field  is  the 
most  significant  bit  (msb)  and  the  right-most  bit  in  the  field  is  the  least  significant  bit  (Isb). 
Whenever  a  multi-octet  field  represents  a  numeric  quantity,  the  left-most  bit  of  the  entire  field  is 
the  msb. 

When  specific  bits  of  fields  are  numbered,  the  msb  is  assigned  the  highest  number,  unless 
otherwise  noted.  For  example,  a  32-bit  field  is  numbered  from  bit  31  down  to  bit  0,  where  bit  31 
is  the  msb. 

This  bit  numbering  convention  differs  from  the  conventions  defined  in  Chapter  4  and  the 
IP  specification.  Table  B-1  shows  the  differences  between  these  different  bit-numbering 
conventions. 


Table  B-1.  Bit  Numbering  Conventions 

Standard 

Bit  Numbering 
Convention 

Single  Octet  Bit  Numbering 

msb 

Isb 

IRIG  Chapter  21-28 

IsbO 

7 

6 

5 

4 

3 

2 

1 

0 
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IRIG  Chanter  4 

msb  1 

1 

2 

3 

4 

5 

6 

7 

8 

IP  Speeification 

msb  0 

0 

1 

2 

3 

4 

5 

6 

7 

Example  Octet  Data  (OxAB) 

1 

0 

1 

0 

1 

0 

1 

1 

B.3.  Octet  (Byte)  Ordering 

Octet  ordering  is  important  for  correct  interpretation  of  multi-octet  fields  in  all  TmNS- 
specific  message  structures.  Unless  otherwise  noted,  these  chapters  specify  the  big-endian 
convention  for  octet  ordering,  which  states  that  whenever  a  multi-octet  field  represents  a  numeric 
quantity,  the  most  significant  octet  is  transmitted  first  and  stored  in  the  memory  location  with  the 
lowest  address. 


NOTE 


The  following  table  illustrates  both  big-endian  and  little-endian  octet 
ordering  for  a  32-bit  field  with  a  value  of  0x9A8B7C6D. 


Big-endian  Transmission  Order/ 
Byte  Address 

0 

1 

2 

3 

32-bitfield  (4  bytes) 

0x9A 

0x8B 

0x7C 

0x6D 

Little-endian  Transmission  Order/ 
Byte  Address 

3 

2 

1 

0 
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Acronyms 

NOT^^ 

Acronyms  in  the  following  list  that  are  marked  with  an  asterisk  appear 
in  this  document  only  in  titles  of  referenced  materials.  Some  of  the 
marked  acronyms  appear  only  once  in  the  document. 

*ADPCM 

AES 

*CIDR 

*CRL 

*DHCP 

*DiffServ 

DSCP 

FTP 

GPS 

*HAIPE 

HTTP 

ICMP 

IGMP 

IP 

IPv4 

ITU 

EEC 

MAC 

MED 

OSI 

*PCM 

*PIM-SM 

PPS 

PTP 

RCC 

RE 

RFC 

RTSP 

SNMP 

SOQPSK 

SSL 

TCP 

TLS 

TMA 

TmNS 

UDP 

URI 

URN 

*USM 

Adaptive  Differential  Pulse  Code  Modulation 

Advanced  Encryption  Standard 

Classless  Inter-Domain  Router 

Certifieate  Revocation  List 

Dynamic  Host  Configuration  Protocol 

Differentiated  Services 

Differentiated  Services  Code  Point 

File  Transfer  Protocol 

Global  Positioning  System 

High  Assurance  Internet  Protocol  Encryptor 

Hypertext  Transfer  Protocol 

Internet  Control  Message  Protocol 

Internet  Group  Management  Protocol 

Internet  Protocol 

Internet  Protocol  version  4 

International  Telecommunication  Union 
logical  link  control 
media  access  control 

Multicast  Listener  Discovery 

Open  Systems  Interconnection 

Pulse  Code  Modulation 

Protocol-Independent  Multicast-Sparse  Mode 
pulse  per  second 

Precision  Time  Protocol 

Range  Commanders  Council 
radio  frequency 

Request  for  Comment 

Real-Time  Streaming  Protocol 

Simple  Network  Management  Protocol 
shaped  offset  quadrature  phase  shift  keying 

Secure  Sockets  Layer 

Transmission  Control  Protocol 

Transport  Layer  Security 

TmNS  manageable  application 

Telemetry  Network  Standard 

User  Datagram  Protocol 

Uniform  Resource  Identifier 

Uniform  Resource  Name 

User-based  Security  Model 
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*VACM 


View-based  Access  Control  Model 
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CHAPTER  22 

Network-Based  Protocol  Suite 


22.1  General 

The  Telemetry  Network  Standard  (TmNS)  leverages  existing  standardized  Internet 
protocols  to  serve  as  the  core  set  of  communication  protocols  used  by  NetworkNodes  within  a 
TmNS  Network.  The  TmNS’s  network-based  protocol  suite  incorporates  a  large  portion  of  the 
Transmission  Control  Protocol  (TCP)/Intemet  Protocol  (IP)  Protocol  Suite  (also  known  as  the 
Internet  Protocol  Suite)  along  with  other  supporting  technologies  (e.g.,  underlying  data  link  and 
physical  layer  technologies).  Figure  22-1  illustrates  the  Open  Systems  Interconnection  (OSI) 
Model,  the  corresponding  TCP/IP  Model,  and  the  major  components  of  the  TCP/IP  Protocol 
Suite. 


Figure  22-1.  OSI  and  TCP/IP  Model  with  TCP/IP  Protocol  Suite 

This  document  follows  the  TCP/IP  Model  layering  convention  and  consists  of  the 
following  major  sections. 

•  Network  Access  Layer:  Consists  of  the  Physical  and  Data  Link  layers  that  define 
the  underlying  hardware  networking  technology.  The  networking  scope  of  this  layer 
is  limited  to  the  local  network  connection. 

•  Internet  Layer  Protocols:  Responsible  for  sending  datagrams  across  potentially 
multiple  networks.  Internetworking  (i.e.,  routing)  requires  sending  data  from  the 
source  network  to  the  destination  network. 
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•  Transport  Layer  Protocols:  Establishes  a  basic  data  channel  that  an  application 
uses  to  exchange  data. 

•  Application  Layer  Protocols:  Includes  protocols  used  by  applications  for 
exchanging  application  data  over  the  network  connections  established  by  the  lower- 
level  protocol.  Basic  network  support  services  are  also  included  (e.g.,  routing  and 
host  configuration  protocols). 

The  bit  numbering,  bit  ordering,  and  byte  ordering  conventions  used  in  this  chapter  are 
described  in  Chapter  21  Appendix  21-B. 

22.1.1  General  NetworkNode  Requirements 

NetworkNodes  with  host  functionality  shah  conform  to  the  following  standards  that 
specify  host  functionality  requirements. 

•  Request  for  Comment  (RFC)  1 122:  Requirements  for  Internet  Hosts  - 
Communication  Layers  ^ 

•  RFC  1123:  Requirements  for  Internet  Hosts  -  Application  and  Support^ 

22.1.2  General  NetworkDevice  Requirements 

NetworkDevices  that  support  IP  version  4  (IPv4)  routing  shah  conform  to  RFC  1812: 
Requirements  for  IP  Version  4  Routers^,  which  specifies  routing  functionality  requirements. 

22.2  Network  Access  Layer 

22.2.1  Physical  Layer 

Connectors  and  cable  media  should  meet  the  electrical  or  optical  properties  required  by 
the  applicable  standards  referenced  herein;  however,  applicability  to  the  selected  operational 
environment  will  place  additional  constraints  on  the  selection  of  the  connectors  and  cable  media. 

22.2. 1 . 1  Wired  Ethernet 

NetworkNodes  shah  support  one  or  more  of  the  bit  rate  and  physical  protocol  standards 
specified  below. 


'  Internet  Engineering  Task  Force.  “Requirements  for  Internet  Hosts  -  Communication  Layers.”  RFC  1 122. 
October  1989.  Updated  by  RFC  8029,  RFC  6864,  RFC  6093,  RFC  5884,  RFC  1349,  RFC  6298,  RFC  6633,  and 
RFC  4379.  Retrieved  18  April  2017.  Available  at  httt)s://datatracker.ietf.org/doc/rfcl  122/. 

^  Internet  Engineering  Task  Force.  “Requirements  for  Internet  Hosts  -  Application  and  Support.”  RFC  1123. 
October  1989.  Updated  by  RFC  5966,  RFC  2181,  RFC  5321,  RFC  7766,  and  RFC  1349.  Retrieved  18  April  2017. 
Available  at  httt)s://datatracker.ietf.org/doc/rfcl  123/. 

^  Internet  Engineering  Task  Force.  “Requirements  for  IP  Version  4  Routers.”  RFC  1812.  June  1995.  Updated  by 
RFC  2644  and  RFC  6633.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf.org/doc/rfc  1812/. 
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22.2.1.1.1  100  megabits  per  second  Ethernet 

22.2.1.1.1.1  100BASE-TX 

Copper  media  connections  using  100BASE-TX  Ethernet  shall  comply  with  IEEE  802.3- 
2012"^,  Section  2,  Clause  25. 

22.2. El.  1.2  lOOBASE-EX 

Multi-mode  fiber  media  connections  using  lOOBASE-EX  Ethernet  shall  comply  with 
IEEE  802.3-2012,  Section  2,  Clause  26. 

22.2.1.1.2  Gigabit  Ethernet 

22.2.1.1.2.1  lOOOBASE-T 

Copper  media  connections  using  lOOOBASE-T  Ethernet  shall  comply  with  IEEE  802.3- 
2012,  Section  3,  Clause  40. 

22.2.1.1.2.2  lOOOBASE-SX 

Multi-mode  fiber  media  connections  using  lOOOBASE-SX  Ethernet  shall  comply  with 
IEEE  802.3-2012,  Section  3,  Clause  38. 

22.2.1.1.2.3  lOOOBASE-EX 

Multi-mode  or  single-mode  fiber  media  connections  using  lOOOBASE-EX  Ethernet  shall 
comply  with  IEEE  802.3-2012,  Section  3,  Clause  38. 

22.2.1.1.3  10  Gigabit  Ethernet 

22.2.1.1.3.1  lOGBASE-T 

Copper  media  connections  using  10  Gigabit  Ethernet  shall  comply  with  IEEE  802.3- 
2012,  Section  5,  Clause  55. 

22.2.1.1.3.2  lOGBASE-SR,  lOGBASE-ER,  lOGBASE-ER 

Eiber  media  connections  using  10  Gigabit  Ethernet  shall  comply  with  IEEE  802.3-2012, 
Section  5,  Clause  52. 

22.2.1.1.4  Auto-Negotiation 

22.2. 1 . 1 .4. 1  Copper  Auto-Negotiation 

Copper  media  connections,  as  described  in  the  preceding  sections,  shall  support  auto¬ 
negotiation  of  speed,  duplex,  and  flow  control  in  the  manner  specified  in  IEEE  802.3-2012, 
Section  2,  Clause  28. 

22.2. 1 . 1 .4.2  Eiber  Auto-Negotiation 

Gigabit  and  10  Gigabit  fiber  media  connections,  as  described  in  the  preceding  sections, 
should  support  auto-negotiation  of  speed,  duplex,  and  flow  control  in  the  manner  specified  in 
IEEE  802.3-2012,  Section  3,  Clause  37. 


^  Institute  of  Electrical  and  Electronics  Engineers.  IEEE  standard  for  ethernet.  IEEE  Std  802.3-2012.  New  York; 
Institute  of  Electrical  and  Electronics  Engineers,  2012. 
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22.2.1.2  Wireless  Technologies 

The  radio  frequency  waveform  of  the  Radio  Access  Network  radios  shall  comply  with 
the  Range  Commanders  Council  (RCC)-Telemetry  Group  variant  of  the  shaped  offset  quadrature 
phase  shift  keying  (SOQPSK-TG)  ternary  constant  phase  modulation  as  defined  in  Chapter  2 
Subsection  2.4. 3. 2. 


Chapter  27  provides  more  details  regarding  the  characteristics  of  the  SOQPSK-TG 
single-carrier  waveform. 


NOTE 


y 


Future  revisions  of  this  standard  may  include  802. 1 1  technologies 
(wireless  Ethernet). 


22.2.2  Data  Link  Layer  Protocols 

NetworkNodes  shall  support  the  Ethernet  data  link  protocols  as  specified  in  IEEE  802.3- 

2012. 

22.2.2.1  Erame  Structure 

NetworkNodes  shall  support  the  frame  structure,  field  definitions,  and  media  access 
control  (MAC)  conventions  specified  in  IEEE  802.3-2012,  Section  1,  Clauses  2,  3,  and  4. 

Data  link  frames  shall  support  48-bit  locally  and  universally  administered  addresses  in  a 
manner  consistent  with  IEEE  802.3-2012,  Section  1,  Clause  3,  Paragraph  3.2.3,  and  Clause  4, 
Paragraph  4.2. 

Data  link  frame  structures  shall  support  type-encapsulated  and  length-encapsulated 
frames  as  specified  in  IEEE  802.3-2012,  Section  1,  Clause  3,  Paragraph  3.2.6. 

22.2.2.2  Media  Access  Control 

NetworkNodes  shall  support  the  MAC  protocols  specified  in  IEEE  802.3-2012,  Section  1, 
Clauses  2,  3,  and  4. 

The  MAC  protocols  shall  convey  type  and  length-encapsulated  frames  to  support  IP 
network  layer  protocols. 

22.2.2.3  Logical  Link  Control  (EEC) 

NetworkNodes  shall  support  the  EEC  protocols  as  specified  in  IEEE  802.2-1998^  to  the 
extent  necessary  to  support  IP  network  layer  protocols. 


^  Institute  of  Electrical  and  Electronics  Engineers.  Information  technology  -  telecommunications  and  information 
exchange  between  systems  -  local  and  metropolitan  area  networks  -  specific  requirements  -  part  2:  logical  link 
control.  IEEE  802.2-1998.  New  York;  Institute  of  Electrical  and  Electronics  Engineers,  1998. 
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22.2.2.4  Link  Layer  Switching 

NetworkDevices  that  perform  link  layer  switching  shall  conform  to  the  requirements  set 
forth  in  IEEE  802.1D-2004®  for  Rapid  Spanning  Tree  Protocol  functionality. 

22.2.2.5  Eink  Eayer  Bridging 

NetworkDevices  that  perform  link  layer  bridging  shall  conform  to  the  requirements  set 
forth  in  IEEE  802.  ID-2004  for  transparent  bridging. 

22.2.2.6  Eink  Eayer  Elow  Control 

NetworkNodes  that  support  full-duplex  Ethernet  shall  support  flow  control  “PAUSE” 
frames  as  specified  in  IEEE  802.3-2012,  Section  3,  Clause  31. 

22.2.2.7  Address  Resolution 

22.2.2. 7. 1  Address  Resolution  Protocol  for  IPv4 

NetworkNodes  that  support  IPv4  shall  conform  to  RPC  826:  Ethernet  Address  Resolution 
Protocol.^ 

22.2.2. 7.2  Neighbor  Discovery  Protocol  for  IPv6 

NetworkNodes  that  support  IPv6  shall  conform  to  the  following  core  link-layer  address 
resolution  standards. 

•  RPC  4861:  Neighbor  Discovery  for  IP  version  6  (IPv6)  ^ 

•  RPC  4862:  IPv6  Stateless  Address  Autoconfiguration^ 

22.3  Internet  Layer  Protocols 

22.3.1  Internet  Protocol  version  4 

NetworkNodes  shall  conform  to  the  following  IPv4  core  standards. 

•  RPC  791:  Internet  Protocol 

•  RPC  919:  Broadcasting  Internet  Datagrams 


®  Institute  of  Electrical  and  Electronics  Engineers.  IEEE  standard  for  local  and  metropolitan  area  networks:  media 
access  control  (MAC)  bridges.  IEEE  802.1-D-2004.  New  York:  Institute  of  Electrical  and  Electronics  Engineers, 
2004. 

^  Internet  Engineering  Task  Force.  “An  Ethernet  Address  Resolution  Protocol.”  RFC  826.  November  1982. 
Updated  by  RFC  5227  and  RFC  5494.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc826/. 

^  Internet  Engineering  Task  Force.  “Neighbor  Discovery  for  IP  version  6  (IPv6).”  RFC  4861.  Updated  by  RFC 
7559,  RFC  5942,  RFC  6980,  RFC  8028,  RFC  7527,  and  RFC  7048.  September  2007.  Available  at 
https://datatracker.ietf.org/doc/rfc4861/. 

®  Internet  Engineering  Task  Force.  ‘TPv6  Stateless  Address  Autoconfiguration.”  RFC  4862.  Updated  by  7527. 
September  2007.  Available  at  https://datatracker.ietf  org/doc/rfc4862/. 

Internet  Engineering  Task  Force.  “Internet  Protocol.”  RFC  791.  Updated  by  RFC  2474,  RFC  6864,  and  RFC 
1349.  September  1981.  Available  at  https://datatracker.ietf  org/doc/rfc791/. 

"  Internet  Engineering  Task  Force.  “Broadcasting  Internet  Datagrams.”  RFC  919.  May  be  superseded  or  amended 
by  update.  October  1984.  Available  at  https://datatracker.ietf  org/doc/rfc9 19/. 
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•  RFC  922:  Broadcasting  Internet  Datagrams  in  the  Presence  of  Subnets*^ 

22.3.1.1  Internet  Control  Message  Protocol  (ICMP) 

NetworkNodes  shall  conform  to  RFC  792:  Internet  Control  Message  Protocol^^  and  shall 
include  support  for  ICMP  broadcast  pings. 


22.3. 1 .2  Internet  Group  Management  Protocol  (IGMP) 

NetworkNodes  that  consume  or  forward  dynamically  configured  IPv4  multicast 
datagrams  shall  conform  to  RFC  3376,  Internet  Group  Management  Protocol,  Version  3.^“^ 


Switching  NetworkDevices  should  use  IGMP  snooping  as  presented  in  RFC  4541: 
Considerations  for  Internet  Group  Management  Protocol  (IGMP)  and  Multicast  Listener 
Discovery  (MLD)  Snooping  Switches.  Such  switching  NetworkDevices  shall  use  at  least  one 
of  the  methods  B  or  C  in  Subsection  2. 1.1.1  of  RFC  4541. 


NOTE 


IGMP  Snooping  is  recommended  for  performance  considerations  in 
a  dynamically  configured  IPv4  multicast  environment. 


22.3.2  Internet  Protocol  version  6  (IPv6) 

NetworkNodes  that  support  IPv6  shall  conform  to  RFC  2460:  Internet  Protocol,  Version 
6  (IPv6)  Specification. 

22.3.2. 1  Internet  Control  Message  Protocol  Version  6  (ICMPv6) 

NetworkNodes  that  support  IPv6  shall  conform  to  RFC  4443:  Internet  Control  Message 
Protocol  (ICMPv6)  for  the  Internet  Protocol  Version  6  (IPv6)  Specification.^^ 

22.3.2.2  Multicast  Listener  Discovery  for  IPv6 

NetworkDevices  that  support  IPv6  should  conform  to  the  following  MLD  standards. 


Internet  Engineering  Task  Force.  “Broadcasting  Internet  Datagrams  in  the  Presence  of  Subnets.”  RFC  922.  May 
be  superseded  or  amended  by  update.  October  1984.  Available  at  https ://datatracker. ietf . org/doc/rfc922/. 

Internet  Engineering  Task  Force.  “Internet  Control  Message  Protocol.”  RFC  792.  Updated  by  RFC  950,  RFC 
4884,  RFC  6633,  and  RFC  6918.  September  1981.  Available  at  https://datatracker.ietf.org/doc/rfc792/. 

Internet  Engineering  Task  Force.  “Internet  Group  Management  Protocol,  Version  3.”  RFC  3376.  Updated  by 
RFC  4604.  October  2002.  Available  at  https ://datatracker. ietf  org/doc/rfc3 376/. 

Internet  Engineering  Task  Force.  “Considerations  for  Internet  Group  Management  Protocol  (IGMP)  and 
Multicast  Listener  Discovery  (MLD)  Snooping  Switches.”  RFC  4541.  May  be  superseded  or  amended  by  update. 
Available  at  https  ://datatracker.  ietf.org/doc/rfc454 1 /. 

Internet  Engineering  Task  Force.  “Internet  Protocol,  Version  6  (IPv6)  Specification.”  RFC  2460.  Updated  by 
RFC  6946,  RFC  5095,  RFC  5722,  RFC  5871,  RFC  7045,  RFC  6935,  RFC  6564,  RFC  7112,  and  RFC  6437. 
December  1998.  Available  at  https://datatracker.ietf  org/doc/rfc2460/. 

Internet  Engineering  Task  Force.  “Internet  Control  Message  Protocol  (ICMPv6)  for  the  Internet  Protocol  Version 
6  (IPv6)  Specification.”  Updated  by  RFC  4884.  March  2006.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc4443/. 
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•  RFC  3810:  Multicast  Listener  Discovery  Version  2  (MLDv2)  for  IPv6* ^ 

•  RFC  4604:  Using  Internet  Group  Management  Protocol  Version  3  (IGMPv3)  and 
Multicast  Listener  Discovery  Protocol  Version  2  (MLDv2)  for  Source-Specific 
Multicast*^ 

22.3.3  IP  Datagram  Transmission 

NetworkNodes  shall  conform  to  the  following  core  standards  for  the  transmission  of  IP 
datagrams. 

•  RFC  894:  A  Standard  for  the  Transmission  of  IP  Datagrams  over  Ethernet 
Networks^** 

•  RFC  1042:  A  Standard  for  the  Transmission  of  IP  Datagrams  over  IEEE  802 
Networks^* 


22.3.4  Protocol  Independent  Multicast 

NetworkDevices  that  perform  routing  functions  shall  conform  to  RPC  4601 :  Protocol 
Independent  Multicast  -  Sparse  Mode  (PIM-SM)  Protocol  Specification  (Revised). 


22.3.5  Network  Routing 


NetworkNodes  (which  includes  NetworkDevices)  shall  be  capable  of  being  configured  to 
use  static  routes  as  defined  in  Section  7.4  of  RPC  1812. 


NOTE 


It  is  expected  that  this  capability  is  a  default  capability  provided  by 
the  host  operating  system  (e.g.  the  linux  route  command). 


NetworkDevices  that  provide  network-layer  services  shall  be  capable  of  being  configured 
to  use  static  routes  for  unicast  and  multicast  traffic. 


NetworkDevices  that  provide  IPv4  routing  functionality  should  be  capable  of  running  the 
interior  routing  protocol  found  in  RPC  2328:  OSPP  Version  2}^ 


Internet  Engineering  Task  Force.  “Multicast  Listener  Discover  Version  2  (MLDv2)  for  IPv6.”  RFC  3810. 
Updated  by  RFC  4604.  June  2004.  Retrieved  18  April  2017.  Available  at  https ://datatracker.ietf. org/doc/rfc3 8 1 0/. 

Internet  Engineering  Task  Force.  “Using  Internet  Group  Management  Protocol  Version  3  (IGMPv3)  and 
Multicast  Listener  Discovery  Protocol  Version  2  (MLDv2)  for  Source-Specific  Multicast.”  RFC  4604.  May  be 
superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf  org/doc/rfc4604/. 

Internet  Engineering  Task  Force.  “A  Standard  for  the  Transmission  of  IP  Datagrams  over  Ethernet  Networks.” 
RFC  894.  May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc894/. 

Internet  Engineering  Task  Force.  “A  Standard  for  the  Transmission  of  IP  Datagrams  over  IEEE  802  Networks.” 
RFC  1042.  February  1988.  May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfcl042/. 

Internet  Engineering  Task  Force.  “Protocol  Independent  Multicast  -  Sparse  Mode  (PIM-SM)  Protocol 
Specification.”  RFC  4601.  Updated  by  RFC  5796,  RFC  6226,  and  RFC  5059.  August  2006.  Retrieved  18  April 
2017.  Available  at  https://datatracker.ietf.org/doc/rfc4601/. 

^Unternet  Engineering  Task  Force.  “OSPF  Version  2.”  RFC  2328.  Updated  by  RFC  6845,  RFC  5709,  RFC  8042, 
RFC  7474,  RFC  6549,  and  RFC  6860.  April  1998.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc2328/. 
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NetworkDevices  that  provide  IPv6  routing  functionality  should  be  capable  of  running  the 
following  interior  routing  protocol:  RFC  5340:  OSPF  for  IPv6.^^ 

22.4  Transport  Layer  Protocols 

22.4.1  Transmission  Control  Protocol 

NetworkNodes  that  implement  TCP  shall  conform  to  RFC  793:  Transmission  Control 
Protocol. 

NetworkNodes  using  TCP  shall  conform  to  RFC  5681:  TCP  Congestion  Control. 

22.4.2  User  Datagram  Protocol  (UDP) 

NetworkNodes  that  implement  UDP  shall  conform  to  RFC  768:  User  Datagram 
Protocol. 

22.4.3  Transport  Laver  Security  (TLS)  and  Secure  Sockets  Laver  (SSL) 

NetworkNodes  that  implement  TLS  and/or  SSL  shall  conform  to  the  following  standards 
for  cryptographic  protocols. 

•  RFC  6101:  The  Secure  Sockets  Layer  (SSL)  Protocol  Version  3.0^* 

•  RFC  5246:  The  Transport  Layer  Security  (TLS)  Protocol  Version  1.2^^ 


It  is  anticipated  that  the  TmNS  will  update  and  follow  the  latest 
government  guidance  for  selection  of  the  exact  SSL  and  TLS 
versions  to  use. 


NOTE 


Certificate  generation  and  exchanges  shall  be  in  accordance  with  the  profile  identified  in 
RFC  5280:  Internet  X.509  Public  Key  Infrastructure  Certificate  and  Certificate  Revocation  List 
(CRL)  Profile. 


2''  Internet  Engineering  Task  Force.  “OSPF  for  IPv6.”  RFC  5340.  Updated  by  RFC  7503,  RFC  6845,  and  RFC 
6860.  July  2008.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf.org/doc/rfc5340/. 

Internet  Engineering  Task  Force.  “Transmission  Control  Protocol.”  RFC  793.  Updated  by  RFC  6093,  RFC 
3168,  RFC  1122,  and  RFC  6528.  September  1981.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc793/. 

Internet  Engineering  Task  Force.  “TCP  Congestion  Control.”  RFC  5681.  September  2009.  May  be  superseded 
or  amended  by  update.  Retrieved  18  April  2017.  Available  at  https ://datatracker. ietf  org/doc/rfc568 1 /. 

Internet  Engineering  Task  Force.  “User  Datagram  Protocol.”  RFC  768.  28  August  1980.  May  be  superseded  or 
amended  by  update.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf  org/doc/rfc768/. 

Internet  Engineering  Task  Force.  “The  Secure  Sockets  Layer  (SSL)  Protocol  Version  3.0.”  RFC  6101.  August 
2011.  May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc6 101/. 

Internet  Engineering  Task  Force.  “The  Transport  Layer  Security  (TLS)  Protocol  Version  1.2.”  RFC  5246. 
Updated  by  many.  August  2008.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf  org/doc/rfc5246/. 

Internet  Engineering  Task  Force.  “Internet  X.509  Public  Key  Infrastructure  Certificate  and  Certificate  Revocation 
List  (CRL)  Profile.”  RFC  5280.  Updated  by  RFC  6818.  May  2008.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf  org/doc/rfc5280/. 
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22.5  Application  Layer  Protocols 

22.5.1  Core  NetworkNode  Protocols 

22.5.1.1  Host/ Address  Configuration 

NetworkNodes  requiring  IPv4  addressing  should  conform  to  RFC  4632:  Classless  Inter- 
Domain  Routing  (CIDR):  The  Internet  Address  Assignment  and  Aggregation  Plan.^^ 

NetworkNodes  requiring  IPv6  addressing  should  conform  to  RFC  4291:  IP  Version  6 
Addressing  Architecture.^^ 

22.5.1.1.1  Static  Configuration 

NetworkNodes  requiring  IPv4  address  configuration  shall  support  static  IP  address 
assignment,  conforming  to  RFC  950:  Internet  Standard  Subnetting  Procedure. 

NetworkNodes  requiring  IPv6  address  configuration  shall  support  static  IP  address 
assignment. 

22.5.1.1.2  Dynamic  Configuration 

A  TmNS  Network  incorporating  IPv4  shall  support  dynamic  IP  address  assignment, 
conforming  to  RFC  2131:  Dynamic  Host  Configuration  Protocol.^'* 

A  TmNS  Network  incorporating  IPv6  shall  support  IPv6  Stateless  Address 
Autoconfiguration  as  specified  in  Subsection  22.2.2.7.2. 

A  TmNS  Network  incorporating  IPv6  that  requires  dynamic  IP  address  assignment  shall 
conform  to  RFC  3315:  Dynamic  Host  Configuration  Protocol  for  IPv6  (DHCPv6).^^ 

22.5.1.2  Domain  Name  Services 

NetworkNodes  that  use  domain  name  labels  shall  conform  to  the  following  core  name 
service  standards. 

•  RFC  1034:  Domain  names  -  concepts  and  facilities'^ 


Internet  Engineering  Task  Force.  “Classless  Inter-domain  Routing  (CIDR):  The  Internet  Address  Assignment  and 
Aggregation  Plan.”  RFC  4632.  August  2006.  May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017. 
Available  at  https://datatracker.ietf.org/doc/rfc4632/. 

Internet  Engineering  Task  Force.  “IP  Version  6  Addressing  Architecture.”  RFC  4291.  Updated  by  RFC  7371, 
RFC  7136,  RFC  5952.  RFC  8064,  RFC  7346,  and  RFC  6052.  February  2006.  Retrieved  18  April  2017.  Available 
at  https  ://datatracker.  ietf  org/doc/rfc429 1 /. 

Internet  Engineering  Task  Force.  “Internet  Standard  Subnetting  Procedure.”  RFC  950.  Updated  by  RFC  6918. 
August  1985.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf  org/doc/rfc950/. 

Internet  Engineering  Task  Force.  “Dynamic  Host  Configuration  Protocol.”  RFC  2131.  Updated  by  RFC  6842, 
RFC  4361,  RFC  5494,  and  RFC  3396.  March  1997.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc2131/. 

Internet  Engineering  Task  Force.  “Dynamic  Host  Configuration  Protocol  for  IPv6  (DHCPv6).”  RFC  3315. 
Updated  by  RFC  7083,  RFC  6221,  RFC  7227,  RFC  5494,  RFC  7283,  RFC  7550,  RFC  4361,  RFC  6644,  and  RFC 
6422.  July  2003.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf  org/doc/rfc33 15/. 

Internet  Engineering  Task  Force.  “Domain  Names  -  Concepts  and  Facilities.”  RFC  1034.  Updated  by  many. 
November  1987.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf.org/doc/rfcl034/. 


22-9 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  22,  July  2017 


•  RFC  1035:  Domain  names  -  implementation  and  specification^^ 


22.5.1.3  Time  Synchronization 

NetworkNodes  requiring  network  time  synchronization  shall  support  network  time 
synchronization  as  specified  in  IEEE  1588-2008:  Precision  Time  Protocol  (PTP)  Version  2.^^ 

22.5.1.3. 1  IEEE  1588  Master  Clock 


NetworkNodes  performing  as  IEEE  1588  masters  shall  support  the  master  clock  interface 
as  specified  in  IEEE  1588-2008. 

Master  clocks  compliant  with  IEEE  1588-2008: 


•  shall  be  able  to  synchronize  with  an  external  source; 

•  should  synchronize  with  the  Global  Positioning  System  (GPS)  external  time  reference 
(see  Subsection  22.5.1.3.5); 

•  shall  use  the  PTP  epoch  when  performing  as  the  IEEE  1588  grandmaster  clock; 

•  shall  use  an  internal  reference  clock  that  tracks  a  best  estimate  of  GPS  time  in  the 
absence  of  an  external  time  synchronization  reference. 


22.5.1.3.2  IEEE  1588  Slave  Clock 


NetworkNodes  requiring  time  synchronization  to  an  IEEE  1588-2008  master  clock  shall 
support  the  slave  clock  interface  as  specified  in  IEEE  1588-2008. 

Slave  clocks  shall  continue  to  run  freely  using  the  last  known  time  in  the  absence  of  a 
grandmaster  clock  on  the  network. 

22.5.  L3. 3  IEEE  1588  Boundary  Clock 

NetworkDevices  that  transport  time  synchronization  data  to  devices  requiring  a  high 
degree  of  synchronization  shall  support  boundary  clock  techniques  or  approaches  that  are 
interoperable  with  boundary  clocks  (e.g.,  transparent  clock  implementations)  as  specified  in 
IEEE  1588-2008. 

22.5.1.3.4  One  Pulse-Per-Second  (1  PPS)  Outputs  on  IEEE  1588  Devices 

NetworkNodes  with  IEEE  1588-2008  master  or  slave  clocks  should  support  external  1 
PPS  outputs  to  allow  verification  of  time  signal  lock  between  distributed  clocks  within  one 
microsecond. 


•  1  PPS  outputs  should  be  compatible  with  standard  O-to-5-volts  direct  current 
transistor-transistor  logic  levels. 

•  The  rising  edge  of  the  pulse  shall  define  the  beginning  of  a  second. 

•  The  duty  cycle  of  the  1  PPS  signal  shall  be  between  5%  and  95%. 


Internet  Engineering  Task  Force.  “Domain  Names  -  Implementation  and  Specification.”  RFC  1035.  Updated  by 
many.  November  1987.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf.org/doc/rfcl035/. 

Institute  of  Electrical  and  Electronics  Engineers.  IEEE  Standard  for  a  Precision  Clock  Synchronization  Protocol 
for  Networked  Measurement  and  Control  Systems.  IEEE  1588-2008.  Geneva;  International  Electrotechnical 
Commission,  2008. 
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•  The  pulse  rise  time  between  the  10%  and  90%  amplitude  points  shall  be  less  than  or 
equal  to  one  microsecond. 

22.5.1.3.5  Global  Positioning  System 

The  GPS  external  time  reference  interface  shall  implement  the  GPS  Space  Segment  RF 
waveform  interface  and  the  GPS  Navigation  User  Segment  interface  as  specified  in  IS-GPS- 
200H,  NAVSTAR  Global  Positioning  System  (GPS)  Interface  Specification.^^ 

22.5.1.3.6  TmNS  Time  Format 

The  TmNS-specific  time  format  describes  a  time  format  for  encoding  timestamps  in  a 
textual  representation. 

TmNStimestamp  =  TmNSdate  "T"  TmNStime 
TmNSdate  =  8DIGIT  ;  <  YYYYMMDD  > 

TmNStime  =  6DIGIT  [  1*9DIGIT  ]  ;  <  hhmmss . fraction  > 

where : 

YYYY  is  the  four-digit  year 
MM  is  month  (01-12) 

DD  is  day  of  the  month  (01-31) 
hh  is  hours  on  a  24-hour  clock  (00-23) 
mm  is  minutes  (00-59) 
ss  is  seconds  (00-59) 

fraction  is  the  fractional  portion  of  the  seconds 

22.5. 1 .4  Information  Assurance  and  Encryption 

22.5.1.4. 1  High  Assurance  Internet  Protocol  Encryptor 

NetworkNodes  that  provide  Information  Assurance  services  shall  comply  with  High 
Assurance  Internet  Protocol  Encryptor  (HAIPE)  Interoperability  Specification  (IS). 

22.5.1.4.2  Advanced  Encryption  Standard  (AES) 

NetworkNodes  that  support  AES  data  encryption  shall  comply  with  NIST  EIPS  PUB  197: 
Advanced  Encryption  Standard  (AES)."^® 

22.5.2  Core  TmNSApp  Protocols 

22.5.2.1  Simple  Network  Management  Protocol  (SNMP) 

All  TmNS  manageable  applications  (TMAs)  shall  conform  to  the  following  management 
protocol  standards. 


Global  Positioning  Systems  Directorate.  “Navstar  GPS  Space  Segment/Navigation  User  Interfaces.”  IS-GPS- 
200H.  24  September  2013.  May  be  superseded  by  update.  Retrieved  18  April  2017.  Available  at 
http://vv'vv'vv'.gr)s.gov/technical/icwg/IS-GPS-200H.t)df. 

National  Institute  of  Standards  and  Technology.  “Specification  for  the  Advanced  Encryption  Standard  (AES).” 
EIPS  PUB  197.  26  November,  2001.  May  be  superseded  by  update.  Available  at 
http://nvlpubs.nist.gov/nistpubs/PIPS/NIST.PIPS.197.pdf. 


22-11 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  22,  July  2017 


•  RFC  3411:  An  Architecture  for  Describing  Simple  Network  Management  Protocol 
(SNMP)  Management  Frameworks^* 

•  RFC  3413:  Simple  Network  Management  Protocol  (SNMP)  Applications'*^ 

•  RFC  2579:  Textual  Conventions  for  SMIv2^^ 

Chapter  25  defines  the  specific  SNMP-based  resources. 

Error  handling  is  detailed  by  the  SNMP  RFCs  referenced  in  this  document.  Some  key 
SNMP  protocol  error  cases  are  emphasized  here  for  clarity: 

•  The  SNMP  exception  value  of  noSuchObject(O)  shall  be  returned  for  each  variable 
not  implemented,  as  stated  in  RFC  3416'*^; 

•  Unsupported  enumerations  or  value  ranges  shall  return  an  SNMP  error-status  of 
inconsistentValue(12),  as  stated  in  RFC  3416. 

22.5.2.1.1  SNMP  Version  3 

The  TMAs  that  implement  SNMPv3  shall  support  the  following  RFCs. 

•  RFC  3410:  Introduction  and  Applicability  Statements  for  Internet  Standard 
Management  Framework'*^ 

•  RFC  3412:  Message  Processing  and  Dispatching  for  the  Simple  Network 
Management  Protocol  (SNMP)"*^ 

•  RFC  3414:  User-based  Security  Model  (USM)  for  version  3  of  the  Simple  Network 
Management  Protocol  (SNMP)^^ 

•  RFC  3415:  View-based  Access  Control  Model  (VACM)  for  the  Simple  Network 
Management  Protocol  (SNMP)"*^ 


Internet  Engineering  Task  Force.  “An  Architecture  for  Describing  Simple  Network  Management  Protocol 
(SNMP)  Management  Frameworks.”  RFC  3411.  Updated  by  RFC  5343  and  RFC  5590.  December  2002. 

Retrieved  18  April  2017.  Available  at  https://datatracker.ietf.org/doc/rfc341 1/. 

Internet  Engineering  Task  force.  “Simple  Network  Management  Protocol  (SNMP)  Applications.”  RFC  3413. 
May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc3413/. 

Internet  Engineering  Task  Force.  “Textual  Conventions  for  SMIv2.”  RFC  2579.  April  1999.  May  be  superseded 
or  amended  by  update.  Retrieved  18  April  2017.  Available  at  https ://datatracker. ietf  org/doc/rfc2579/. 

Internet  Engineering  Task  Force.  “Version  2  of  the  Protocol  Operations  for  the  Simple  Network  Management 
Protocol  (SNMP).”  RFC  3416.  December  2002.  May  be  superseded  or  amended  by  update.  Retrieved  18  April 
2017.  Available  at  https ://datatracker. ietf.org/doc/rfc34 1 6/. 

Internet  Engineering  Task  Force.  “Introduction  and  Applicability  Statements  for  Internet  Standard  Management 
Framework.”  RFC  3410.  December  2002.  May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017. 
Available  at  https  ://datatracker.  ietf.org/doc/rfc34 1 0/. 

Internet  Engineering  Task  Force.  “Message  Processing  and  Dispatching  for  the  Simple  Network  Management 
Protocol  (SNMP).”  RFC  3412.  Updated  by  RFC  5590.  December  2002.  Retrieved  18  April  2017.  Available  at 
https  ://datatracker.  ietf  org/doc/rfc34 1 2/. 

Internet  Engineering  Task  Force.  “User-based  Security  Model  (USM)  for  version  3  of  the  Simple  Network 
Management  Protocol  (SNMPv3).”  RFC  3414.  Updated  by  RFC  5590.  December  2002.  Retrieved  18  April  2017. 
Available  at  https  ://datatracker.  ietf.org/doc/rfc34 1 4/. 

Internet  Engineering  Task  Force.  “View-based  Access  Control  Model  (VACM)  for  the  Simple  Network 
Management  Protocol  (SNMP).”  RFC  3415.  December  2002.  May  be  superseded  or  amended  by  update. 

Retrieved  18  April  2017.  Available  at  https ://datatracker. ietf. org/doc/rfc34 15/. 
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•  RFC  3417:  Transport  Mappings  for  the  Simple  Network  Management  Protocol 
(SNMP)^'^ 

•  RFC  3826:  The  Advanced  Encryption  Standard  (AES)  Cipher  Algorithm  in  the 
SNMP  User-based  Security  Model^° 

22.5.2.1.2  SNMP  Version  2c 

The  TMAs  that  implement  SNMPv2c  shall  support  the  following  RECs. 

•  REC  1901:  Introduction  to  Community-based  SNMPv2^' 

•  REC  2578:  Structure  of  Management  Information  Version  2  (SMIv2)^^ 

•  REC  3416 

22.5.2.2  Hypertext  Transfer  Protocol  (HTTP) 

The  TmNSApps  that  support  HTTP  shall  conform  to  the  following  protocol  standards. 

•  RPC  7230:  Hypertext  Transfer  Protocol  (HTTP/1.1):  Message  Syntax  and  Routing^^ 

•  RPC  7231:  Hypertext  Transfer  Protocol  (HTTP/1.1):  Semantics  and  Content^'* 

•  RPC  7232:  Hypertext  Transfer  Protocol  (HTTP/1.1):  Conditional  Requests^^ 

•  RPC  7233:  Hypertext  Transfer  Protocol  (HTTP/1.1):  Range  Requests^® 

•  RPC  7234:  Hypertext  Transfer  Protocol  (HTTP/1.1):  Caching^’ 


Internet  Engineering  Task  Force.  “Transport  Mappings  for  the  Simple  Network  Management  Protocol  (SNMP).” 
RFC  3417.  Updated  by  RFC  4789  and  R  FC  5590.  December  2002.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc3417/. 

Internet  Engineering  Task  Force.  “The  Advanced  Encryption  Standard  (AES)  Cipher  Algorithm  in  the  SNMP 
User-based  Security  Model.”  RFC  3826.  June  2004.  May  be  superseded  or  amended  by  update.  Retrieved  18 
April  2017.  Available  at  https://datatracker.ietf.org/doc/rfc3826/. 

Internet  Engineering  Task  Force.  “Introduction  to  Community-based  SNMPv2.”  RFC  1901.  January  1996.  May 
be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc  1901/. 

Internet  Engineering  Task  Force.  “Structure  of  Management  Information  Version  2  (SMIv2).”  RFC  2578.  April 
1999.  May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc2578/. 

Internet  Engineering  Task  Force.  “Hypertext  Transfer  Protocol  (HTTP/1.1):  Message  Syntax  and  Routing.”  RFC 
7230.  June  2014.  May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https  ://datatracker.  ietf  org/doc/rfc7 230/. 

Internet  Engineering  Task  Force.  “Hypertext  Transfer  Protocol  (HTTP/1.1):  Semantics  and  Content.”  RFC  7231. 
June  2014.  May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc7231/. 

Internet  Engineering  Task  Force.  “Hypertext  Transfer  Protocol  (HTTP/1.1):  Conditional  Requests.”  RFC  7232. 
June  2014.  May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc7232/. 

Internet  Engineering  Task  Force.  “Hypertext  Transfer  Protocol  (HTTP/1.1):  Range  Requests.”  RFC  7233.  June 
2014.  May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc7233/. 

Internet  Engineering  Task  Force.  “Hypertext  Transfer  Protocol  (HTTP/1.1):  Caching.”  RFC  7234.  June  2014. 
May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc7234/. 
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•  RFC  7235:  Hypertext  Transfer  Protocol  (HTTP/1.1):  Authentication^^ 

22.5.2.3  Real  Time  Streaming  Protocol  (RTSP) 

The  TmNSApps  that  support  TmNS  Data  Delivery  using  a  DataDeliveryControlChannel 
shall  exchange  control  commands  and  parameters  using  RTSP,  as  specified  in  RFC  2326:  Real 
Time  Streaming  Protocol  (RTSP).^^ 

Chapter  26  defines  the  DataDeliveryControlChannel,  which  is  an  augmentation  of  the 
RTSP  specification. 

22.5.2.4  File  Transfer 

The  TmNSApps  that  support  file  transfer  services  shall  support  RFC  959:  File  Transfer 
Protocol  (FTP).^° 

22.5.2.5  Voice  Over  IP 

The  TmNSApps  that  provide  voice  services  shall  comply  with  one  or  more  of  the 
following  Voice  over  IP  standards. 

•  International  Telecommunication  Union  (ITU)  H.323  Packet  Based  Multimedia 
Communication®* 

•  RFC  3261:  SIP:  Session  Initiation  Protocol®^ 

•  RFC  3550:  RTP:  A  Transport  Protocol  for  Real-Time  Applications®^ 

The  TmNSApps  that  provide  voice  services  shall  comply  with  one  or  more  of  the 
following  coder-decoder  standards. 

•  ITU-T  G.7 1 1  -  Pulse  Code  Modulation  (PCM)®^ 

•  ITU-T  G.726  -  Adaptive  Differential  Pulse  Code  Modulation  (ADPCM)®® 


Internet  Engineering  Task  Force.  “Hypertext  Transfer  Protocol  (HTTP/1.1):  Authentication.”  RFC  7235.  June 
2014.  May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc7235/. 

Internet  Engineering  Task  Force.  “Real  Time  Streaming  Protocol  (RTSP).”  RFC  2326.  Obsoleted  by  RFC  7826. 
April  1998.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf.org/doc/rfc2326/. 

“  Internet  Engineering  Task  Force.  “File  Transfer  Protocol  (FTP).”  RFC  959.  Updated  by  RFC  3659,  RFC  7151, 
RFC  2640,  RFC  2773,  RFC  2228,  and  RFC  5797.  October  1985.  Retrieved  18  April  2017.  Available  at 
https  ://datatracker.  ietf  org/doc/rfc959/. 

International  Telecommunication  Union.  “Packet-based  multimedia  communications  systems.”  ITU-T  H.323. 
December  2009.  May  be  superseded  by  update.  Retrieved  18  April  2017.  Available  at  https://www.itu.int/rec/T- 
REC-H.323/en. 

®  Internet  Engineering  Task  Force.  “SIP:  Session  Initiation  Protocol.”  RFC  3261.  Updated  by  many.  June  2002. 
Retrieved  18  April  2017.  Available  at  https://datatracker.ietf.org/doc/rfc3261/. 

Internet  Engineering  Task  Force.  “RTP:  A  Transport  Protocol  for  Real-Time  Applications.”  RFC  3550.  Updated 
by  RFC  7022,  RFC  5761,  RFC  8108,  RFC  8083,  RFC  6222,  RFC  6051,  RFC  5506,  RFC  7160,  and  RFC  7164.  July 
2003.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf  org/doc/rfc3550/. 

International  Telecommunication  Union.  “Pulse  Code  Modulation  (PCM)  of  Voice  Frequencies.”  ITU-T  G.7 1 1 . 
May  be  superseded  by  update.  Retrieved  18  April  2017.  Available  at  https://www.itu.int/rec/T-REC-G.71 1/en. 

“  International  Telecommunication  Union.  “40,  32,  24,  16  kbit/s  Adaptive  Differential  Pulse  Code  Modulation 
(ADPCM).”  ITU-T  G.726.  14  December  1990.  May  be  superseded  by  update.  Retrieved  18  April  2017. 

Available  at  https://www.itu.int/rec/T-REC-G.726/en. 
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22.5.2.6  Secure  Communications 

The  TmNSApps  requiring  secure,  reliable  network  communication  over  connection- 
oriented  transports  shall  conform  to  RFC  5246. 

The  TmNSApps  requiring  secure  network  communication  over  SNMP  shall  conform  to 
RFC  5953:  Transport  Layer  Security  (TLS)  Transport  Model  for  the  Simple  Network 
Management  Protocol  (SNMP).^® 

Specific  implementation  may  require  additional  security. 


NOTE 


The  SNMP  incorporates  a  security  model  that  utilizes  TLS.  The 
open-source  Net-SNMP  implementation  has  supported  both  TLS 
and  Datagram  TLS  (DLLS)  since  version  5.6. 


22.5.2.6.1  Secure  FTP 

The  TmNSApps  that  support  secure  file  transfer  services  shall  support  the  following 
protocols. 

•  RFC  2228:  FTP  Security  Extensions'^ 

•  RFC  4217:  Securing  FTP  with  TLS 

22.5.2.6.2  Secure  HTTP 

The  TmNSApps  that  support  secure  HTTP  services  should  follow  the  recommendations 
inRFC  2818:  HTTP  Over  TLS . 

22.5.2.7  Uniform  Resource  Identifier  (URI)/Uniform  Resource  Name  (URN) 

TmNSApps  shall  conform  to  the  following  standards  governing  URFURN  syntax. 

•  RFC  3986:  Uniform  Resource  Identifier  (URI):  Generic  Syntax^® 


“  Internet  Engineering  Task  Force.  “Transport  Layer  Security  (TLS)  Transport  Model  for  the  Simple  Network 
Management  Protocol  (SNMP).”  RFC  5953.  Obsoleted  by  RFC  6353.  August  2010.  Retrieved  18  April  2017. 
Available  at  https  ://datatracker.  ietf.org/doc/rfc595 3/. 

Internet  Engineering  Task  Force.  “FTP  Security  Extensions.”  RFC  2228.  October  1997.  May  be  superseded  or 
amended  by  update.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf  org/doc/rfc2228/. 

Internet  Engineering  Task  Force.  “Securing  FTP  with  TLS.”  RFC  4217.  October  2005.  May  be  superseded  or 
amended  by  update.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf  org/doc/rfc4217/. 

®  Internet  Engineering  Task  Force.  “HTTP  Over  TLS.”  RFC  2818.  Updated  by  RFC  5785  and  RFC  7230.  May 
2000.  Retrieved  18  April  2017.  Available  at  https://datatracker.ietf  org/doc/rfc28 1 8/. 

Internet  Engineering  Task  Force.  “Uniform  Resource  Identifier  (URI):  Generic  Syntax.”  RFC  3986.  Updated  by 
RFC  7320  and  RFC  6874.  January  2005.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc3986/. 
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•  RFC  3406 

:  Uniform  Resource  Names  (URN)  Namespace  Definition  Mechanisms 

NOT^^ 

The  TmNS-specific  URN  is  not  registered.  It  is  anticipated  that  the 
RCC  may  register  it  in  the  future. 

22.5.3  Quality  of  Service 


22.5.3.1  Differentiated  Services  (DiffServ) 

NetworkNodes  shall  support  the  DiffServ  standards  as  specified  in: 


RFC  2474:  Definition  of  the  Differentiated  Services  Field  (DS  Field)  in  the  IPv4  and 
IPv6  Headers 

RFC  2475:  An  Architecture  for  Differentiated  Services 

RFC  2597:  Assured  Forwarding  PHB  Group 

RFC  3140:  Per  Hop  Behavior  Identification  Codes;^^ 

RFC  3246:  An  Expedited  Forwarding  PHB  (Per-Hop  Behavior);^^ 

RFC  4594:  Configuration  Guidelines  for  DiffServ  Service  Classes.’^ 


22.5.3.2  DiffServ  Code  Point  (DSCP)  Assignments 

NetworkNodes  shall  mark  IP  packets  with  DSCP  markings  as  specified  through 
configuration  via  an  MDL  file. 

The  DSCP  assignments  identified  in  Table  22-1  have  restricted  usage  and  shall  only  be 
assigned  to  network  traffic  that  is  directly  related  to  network  and  internetwork  control,  such  as 
RF  network  messages  that  are  exchanged  between  RF  link  management  and  radios. 
NetworkNodes  shall  not  mark  traffic  with  the  restricted  DSCP  assignments  if  the  traffic  is  not 
directly  related  to  network  and  internetwork  control. 


Internet  Engineering  Task  Force.  “Uniform  Resource  Names  (URN)  Namespace  Definition  Mechanisms.”  RFC 
3406.  October  2002.  May  be  superseded  or  amended  by  update.  Available  at 
https://datatracker.ietf.org/doc/rfc3406/. 

Internet  Engineering  Task  Force.  “Definition  of  the  Differentiated  Services  Field  (DS  Field)  in  the  IPv4  and  IPv6 
Headers.”  RFC  2474.  Updated  by  RFC  3260  and  RFC  3168.  December  1998.  Retrieved  18  April  2017.  Available 
at  https://datatracker.ietf.org/doc/rfc2474/. 

Internet  Engineering  Task  Force.  “An  Architecture  for  Differentiated  Services.”  RFC  2475.  Updated  by  RFC 
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Table  22-1.  Restricted  DSCP  Assignments 

DSCP 

Class 

IP  Precedence 

DSCP  Range 

Comment 

6 

Internetwork  Control 

6’bl  10000  (6’d48)- 
6’bllOlll  (6’d55) 

Used  for  IP  routing  protocols 

7 

Network  Control 

6’bl  11000  (6’d56)- 
6’bllllll  (6’d63) 

Link  layer  and  routing  protocol 
keep  alive 

NetworkDevices  forwarding  IP  packets  with  unrecognized  DSCP  values  shall  forward  the 
packets  with  the  DSCP  value  unchanged  but  queue  the  packets  using  the  PHB  of  6’bOOOOOO. 
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APPENDIX  22-A 

Default  DSCP  Traffic  Classification  for  TmNS -based  Systems 

The  DSCP  markings  to  be  assigned  to  network  traffic  in  a  TmNS-based  system  are 
described  in  the  MDL  configuration  file  for  the  test.  The  default  DSCP  markings  to  be 
associated  with  different  types  of  traffic  in  a  TmNS-based  system  are  described  in  Table  A-1. 


Table  A-1.  DSCP  Traffic  Classifications  for  TmNS-based  Systems  ^ 

IEEE  802.1Q  PCP  -  IEEE 
P802.Ip 

DSCP  Category 
Description 

Expected  Use  Within  TmNS- 
based  System 

0  -  Best  Effort 

Best  Effort 

DSCP  0:  General  Network 

Traffic  (e.g.  FTP) 

1  -  Background 

Class  1 

DSCP  8:  RC  Delivery  at  Normal 
Priority  &  System  Management 
Status 

2  -  Excellent  Effort 

Class  2 

DSCP  16:  ETC  Delivery 

3  -  Critical  Applications 

Class  3 

DSCP  24:  RC  Delivery  at  High 
Priority 

4  -  “Video,”  <  100  ms 
latency  &  jitter 

Class  4 

DSCP  32:  System  Management 
Control  &  Video 

5  -  “Voice,”  <  10  ms  latency 
and  jitter 

Expedited  Eorwarding 
(EE) 

DSCP  40:  Voice 

6  -  Internetwork  Control 

Control  (used  for  IP 
routing  protocols) 

DSCP  48:  RE  Network  Messages 

7  -  Network  Control 

Control  (link  layer  and 
routing  protocol  keep 
alive) 

DSCP  56:  RE  Network  Messages 
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CHAPTER  23 

Metadata  Configuration 


23.1  Introduction 

This  chapter  describes  system  configuration  data  for  network-based  telemetry  systems  in 
a  common  fashion,  and  provides  a  language  for  describing  the  configuration  of  all  of  the 
components  in  a  telemetry  system,  as  well  as  their  logical  and  physical  interrelationships.  The 
language  is  intended  to  be  expressive  enough  to  describe  a  wide  variety  of  systems:  large  and 
small,  simple  and  complex,  from  the  low-level  transducer-to-measurement  association  for  an 
acquisition  card  on  a  data  acquisition  unit  up  to  network  topology  of  multiple  test  mission 
networks. 

This  chapter  defines  the  Metadata  Description  Language  (MDL),  which  has  a  syntax  that 
defines  vocabulary  and  sentence  structure,  while  the  MDL  semantics  provide  meaning.  Using 
the  MDL  syntax  and  semantics,  MDL  instance  documents  can  be  created  to  describe  telemetry 
systems.  The  descriptions  may  be  used  in  various  ways:  to  configure  components,  to  predict  the 
performance  of  the  network,  or  to  capture  requirements  for  the  telemetry  system.  Additionally, 
the  MDL  provides  a  common  exchange  language  that  facilitates  the  interchange  of  configuration 
information  between  telemetry  system  components. 


23.2  Metadata  Description  Language 


The  MDL  is  described  only  as  an  extensible  Markup  Language  (XML)  schema.  The 
MDL  XML  language  schema  consists  of  an  XML  schema  document  (XSD)  file  that  defines  the 
structure  of  valid  MDL  instance  documents.  Additionally,  an  automatic  transformation  process 
is  applied  to  the  schema  in  order  to  create  a  graphical  depiction  of  the  schema  in  Hyper  Text 
Markup  Language  (HTML)  format.  The  schema  and  HTML  depiction  are  available  here. 


NOTE 


The  MDL  XML-based  schema  is  not  intended  to  be  read  in  a  plain  text 
fashion.  The  HTML  graphical  depiction  is  provided  as  an  aid  for  those 
desiring  to  read  the  schema. 


23.2.1  MDL  Schema  Concepts 


The  MDL  schema  defines  a  syntax,  which  includes  a  vocabulary,  a  set  of  types,  and  the 
rules  for  how  an  MDL  instance  document  shall  be  structured.  The  syntax  definition  is  realized 
using  the  XML  Schema  standard,  which  is  maintained  by  the  World  Wide  Web  Consortium 
(W3C  -  www.w3.org). 


NOTE 


The  MDL  builds  upon  the  existing  schema  standard  of  the  W3C.  Readers 
unfamiliar  with  W3C  schemas  as  a  whole  are  encouraged  to  study  basic 
concepts  from  the  W3C  prior  to  attempting  to  understand  the  MDL. 


Constraints  as  defined  by  the  W3C  are  a  part  of  the  MDL  schema.  In  the  MDL  schema 
implementation,  these  constraints  are  distributed  between  statements  that  are  syntax-related 
(encoded  and  enforced  by  the  schema)  and  statements  that  are  semantic-related  (additional  rules 
that  are  levied  and  provide  meaning).  The  syntax  of  the  language  is  enforced  using  W3C  XML 
Schema  constraints. 
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When  possible,  XML  mechanisms  are  used  to  enforce  semantic  constraints.  In  cases  not 
supported  cleanly  by  XML,  text  has  been  added  directly  to  the  MDL  schema  documentation.  In 
such  cases,  the  text  will  typically  include  the  keyword  “shall”.  The  phrase  “the  value  of  the 
Name  element  of  the  Measurement  element  shall  be  unique”  is  one  such  example. 


NOTE 


Not  all  constraints  that  must  be  met  in  order  for  an  MDL  file  to  be  valid  for 
configuration  can  be  expressed  by  W3C  constraints.  Plain  text  is  used  in  the 
schema  to  describe  such  cases.  Additionally,  applications  consuming  or  generating 
MDL  instance  documents  are  expected  to  assure  that  the  files  are  valid. 


23.2. 1 . 1  Conditional  elements  in  the  MDL  Schema  Definition  File 


The  MDL  schema  is  a  system-level  description.  Not  all  components  require  every 
element  to  properly  configure.  In  such  cases,  these  elements  are  conditional.  The 
documentation  specifies  when  the  conditional  elements  shall  be  present  and  processed. 
Components  not  specifically  called  out  in  documentation  of  conditional  elements  shall  not  fail  to 
configure  if  the  particular  conditional  element  is  not  present. 


NOTE 


y 


Use  of  “conditional”  over  “optional”  is  an  intentional  style  chosen  for  the 
MDL  grammar.  Conditional  is  preferred  in  order  to  remove  ambiguity 
concerning  grammar  elements  that  must  be  considered  by  devices 
exchanging  MDL  files  that  are  to  be  used  for  configuration. 


23.2. 1 .2  Naming  conventions  in  the  MDL  Schema  Definition  File 

In  the  MDL  schema  definition  file,  MDL  elements  and  attributes  appear  as  instances  of 
defined  xsd;  complexType  and  xsd;  simpleType  elements.  Each  declaration  of  these  MDL- 
specific  elements  will  specify  a  name  attribute  that  is  assigned  a  string  that  contains  the  name  of 
the  MDL  element  being  described  followed  by  a  string  suffix  of  “Type”  or  “Enum”.  Eor 
example,  the  top-level  element  of  the  MDE  schema  is  the  MDLRoot  element.  In  the  MDE 
schema  definition  file,  this  element  appears  as  an  instance  of  an  xsd ;  complexType  element 
with  a  name  attribute  of  “MDERootType”.  These  name  attribute  strings  that  correspond  to  the 
defined  MDE  elements  only  appear  in  the  MDE  schema  definition  file. 

23.2.1.3  Indexing  policies 

Numerical  indices  present  in  an  MDE  instance  document  are  recommended  to  count 
starting  at  1  and  to  increment  by  one  (i.e.,  1,  2,  3,  4,...). 

23.2. 1 .4  Uniqueness  of  ID  attributes 

Values  of  ID  attributes  of  any  element  within  an  MDE  instance  document  shall  be 
unique.  The  ID  attributes  are  used  to  implement  references. 

23.2. 1 .5  Extending  MDE  with  supplementary  XME-based  standards 

The  use  of  other  XME-based  standards  (i.e.,  other  schemas)  in  conjunction  with  the  MDE 
schema  is  permitted.  Potentially,  the  use  of  these  external  standards  through  their  accompanying 
schemas  leverages  existing  knowledge  to  describe  concepts  and  domains  beyond  those  in  the 
MDE.  The  MDE  does  not  explicitly  constrain  the  available  mechanisms  to  use  external 
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standards;  however,  the  linking  of  external  schemas  to  the  MDL  schema  shall  not  result  in  the 
modification  of  the  MDL  schema. 

23.2. 1 .6  Usage  of  Telemetry  Attributes  Transfer  Standard  in  MDL 

The  MDL  schema  requires  the  tmatsP  :  PCMFormatAttributesType  to  describe  pulse 
code  modulation  (PCM)  measurements,  and  it  is  imported  directly  from  the  Telemetry  Attributes 
Transfer  Standard  (TMATS)  schema.  The  TMATS  schema  files  are  included  with  the  MDL 
schema  for  convenience,  and  are  also  available  in  Chapter  9. 

23 .2. 1 .7  Usage  of  GenericParameter  Element 

The  GenericParameter  element  allows  the  description  of  additional  information 
outside  the  scope  of  the  MDL,  and  may  also  be  used  to  document  decisions  made  to  arrive  at  a 
vendor- specific  configuration.  GenericParameter  shall  be  used  to  extend  the  MDL  grammar 
when  it  cannot  support  those  required  concepts  natively,  or  as  a  key  so  that  vendor  tools  can 
arrive  at  the  same  configuration  as  in  a  previous  run. 

23.2. 1.8  Recommended  Best  Practices 

Appendix  23-C  contains  a  table  of  recommended  best  practices  to  further  enhance 
interoperability. 

23.2.2  MDL  Global  Element  Glossary 

The  MDE  schema  contains  a  large  number  of  xsd;  documentation  elements  that 
describe  the  intent,  purpose,  or  usage  of  the  elements  in  MDE.  These  embedded  annotations 
collectively  form  the  global  element  glossary  for  the  MDE  schema.  The  glossary  can  be  viewed 
here  (the  MDE  Schema  Documentation.html  file  located  in  the  compressed  folder  this  link 
opens).  It  is  automatically  produced  from  the  schema  file  by  way  of  an  extensible  Stylesheet 
Eanguage  stylesheet,  which  renders  the  documentation  as  HTME. 
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APPENDIX  23-A 
MDL  Examples 

Example  MDL  files  (XML  instance  documents)  and  associated  documentation  are  here. 
As  with  most  grammars,  it  is  expected  that  the  examples  will  be  very  useful  in  clarifying  the 
expected  use  of  MDL;  however,  the  documentation  of  the  schema  takes  precedence  over 
concepts  or  details  that  may  be  inferred  through  the  examples. 
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APPENDIX  23-B 
MDL  Relationships  to  Chapters 

The  MDL  is  used  to  deseribe  system  configuration  data  for  network-based  telemetry 
systems;  therefore,  it  includes  elements  to  describe  the  concepts  presented  across  Chapters  22 
through  28.  Table  B-1  provides  a  mapping  of  the  relevant  top-level  MDL  elements  and  their 
relationships  to  these  chapters. 


Table  B-1.  MDL  Mapping  to  RCC  106  Chapters 

MDLRoot  Element 

Relationship 

RCC  106  Chapter 

TestMissions 

Data  Protocol 

22:  Network-Based  Protocol  Suite 

Management 

26:  TmNSDataMessage  Transfer  Protocol 

MeasurementDomains 

Message  Internals 

24:  Message  Formats 

NetworkDomains 

Network  Shape 

22:  Network-Based  Protocol  Suite 

Network  Use 

25:  Management  Resources 

Network  Management 

26:  TmNSDataMessage  Transfer  Protocol 

RANConfigs 

Radio  Links 

27:  RF  Network  Access  Layer 

Radio  Management 

28:  RF  Network  Management 

DSCPTable 

Quality  of  Service 

22:  Network-Based  Protocol  Suite 

Additionally,  MDL_vO_9_4_chapter_mapping.xslx  inside  the  compressed  folder  linked 
here  provides  a  detailed  mapping  of  all  MDL  elements  to  Chapter  22  through  28. 
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APPENDIX  23-C 

MDL  Recommended  Best  Practices 


Table  C-1  provides  recommended  best  practices  for  creating  MDL  instance  documents 
that  will  enhance  interoperability. 


Table  C-1.  MDL  Recommended  Best  Practices 

Scenario 

MDL  Syntax/Semantics 

Related 

Scenarios 

1 .  Measurement  Name 
Scoping  for  External 
Usage 

Any  of  the  following  can  be  used  to  identify  a  measurement. 
External  tool  representation  examples: 

•  Multiple  Test  Article  (TA),  Multiple  Transport  Case 

o  TA/TRANSPORT/MEASUREMENT  (e.g., 

Weapon  1/PCM  1/Airspeed) 

•  Single  TA,  Multiple  Transport  Case 

o  */TRANSPORT/MEASUREMENT  (e.g., 

*/PCM  1  /Airspeed) 

•  Multiple  TA,  Single  Transport  Case 

o  TA/*/MEASURMENT  (e.g., 

W  eapon  1  /*/ Airspeed) 

•  Single  TA,  Single  Transport  Case 

o  */*/MEASUREMENT  (e.g.,  */*/Airspeed) 

The  recommended  delimiter  is  the  forward  slash  (/)  character. 
When  fields  are  not  required  to  uniquely  identify  a  measurement, 
the  recommended  wildcard  is  the  asterisk  (*)  character. 
Measurement  names  should  avoid  embedded  blanks  or  special 
characters  other  than   and  -. 

None 

2.  Choosing  the  Correct 
DataProcessing 

Function  Type 

If  a  DataProcessing  Function  can  be  represented  by  a 
LookupTable  element  or  a  Polynomial  element  then  these 
Function  types  should  be  used  instead  of  the  generic 

Algorithm  element. 

Polynomial  example: 

<Function> 

<Name>Polynomial  Example</Name> 

<Description> (5x**2  +  6x  +  7 )  /  (2.5x**3  + 
3x*l . 64) </Description> 

<InputCount>l</InputCount> 

<UpdateFrequency>I f Any</UpdateFrequency> 
<Polynomial> 

<Numerator> 

<Term> 

<Coefficient>5</ Co efficient > 
<Exponent >2 < /Exponent > 

</Term> 

<Term> 

<Coefficient>6</ Co efficient > 

3. 

Specifying 
Points  in  a 
LookupTab 
le 
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Table  C-1.  MDL  Recommended  Best  Practices 

Scenario 

MDL  Syntax/Semantics 

Related 

Scenarios 

<Exponent>l</Exponent> 

</Term> 

<Term> 

<Coefficient>7</Coefficient> 
<Exponent>0< /Exponent > 

</Term> 

</Numerator> 

<Denominator> 

<Term> 

<Coefficient>2 .5</ Co efficient > 
<Exponent>3< /Exponent > 

</Term> 

<Term> 

<Coefficient>3</ Co efficient > 
<Exponent>l . 64</Exponent> 

</Term> 

</Denominator> 

</Polynomial> 

</Function> 

3.  Specifying  Points  in  a 
LookupTable 

When  defining  a  LookupTable  in  a  DataProcessing 
Function  the  complete  set  of  points  should  be  provided, 
including  -i-/-Inf.  If  all  points  are  not  provided,  then  the 
LookupTable  output  is  undefined  for  those  input  points. 
LookupTable  example: 

<Function> 

<Name>LookupTable  Example</Name> 
<Description>Example  showing  a  lookup 
table</Description> 

<InputCount>l</InputCount> 

<UpdateFrequency>I f Any</UpdateFrequency> 
<LookupTable> 

<LookupTableEntry> 

<InputValue>NegativeInf inity</ InputValue> 
<OutputValue>0 . 0</OutputValue> 
</LookupTableEntry> 

<LookupTableEntry> 

<InputValue>0</InputValue> 
<OutputValue>0 . 0</OutputValue> 
</LookupTableEntry> 

<LookupTableEntry> 

<InputValue>l</InputValue> 
<OutputValue>l . 0</OutputValue> 
</LookupTableEntry> 

<LookupTableEntry> 

<InputValue>2</InputValue> 

None 
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Table  C-1.  MDL  Recommended  Best  Practices 

Scenario 

MDL  Syntax/Semantics 

Related 

Scenarios 

<OutputValue>5 . 0</OutputValue> 
</Look;upTableEntry> 

<Look;upTableEntry> 

<InputValue>PositiveInf inity</ InputValue> 
<OutputValue>6 . 0</OutputValue> 
</Look;upTableEntry> 

</Look;upTable> 

</Eunction> 

4.  Using 

MeasurementTimeRefs 
in  Packages 

Packages  should  only  contain  one  instance  of  time  (a  single 
MeasurementTimeRef )  per  set  of  measurements  taken  at  that 
time. 

MeasurementTimeRef  example: 

<DataMaps> 

<DataWordToEieldMap> 

<DataWord> 

<Name>Measurement  1</Name> 
<Description>Simultaneously  sampled 
measurement </Description> 

<DataWordWidth> 

<Value>16</Value> 

<BaseUnit>Bit</BaseUnit> 

</DataWordWidth> 

<MeasurementRef  IDREE="Measl "/> 
<Syllables> 

<Syllable> 

<Name>Measurement  1 

Sy 11 able < /Name > 

</Syllable> 

</Syllables> 

</DataWord> 

<DataStructureEieldRef 

IDREE="Packagel_Eieldl"/> 

<TimeOrder>IncreasingTemporal</TimeOrder> 

</DataWordToEieldMap> 

<DataWordToEieldMap> 

<DataWord> 

<Name>Measurement  2</Name> 
<Description>Simultaneously  sampled 
measurement </Description> 

<DataWordWidth> 

<Value>16</Value> 

<BaseUnit>Bit</BaseUnit> 

</DataWordWidth> 

<MeasurementRef  IDREE="Meas2 "/> 

None 
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Table  C-1.  MDL  Recommended  Best  Practices 

Scenario  MDL  Syntax/Semantics  Related 

_ Scenarios 

<Syllables> 

<Syllable> 

<Name>Measurement  2 

Sy 11 able < /Name > 

</Syllable> 

</Syllables> 

</DataWord> 

<DataStructureFieldRef 
IDREF="Packagel_Field2 "/> 

<TimeOrder>IncreasingTemporal</TimeOrder> 

</DataWordToFieldMap> 

<DataWordToFieldMap> 

<DataWord> 

<Name>Time  Measurement</Name> 
<Description>Time  that  the 
simultaneously  sampled  measurements  were 
taken</Description> 

<DataWordWidth> 

<Value>16</Value> 

<BaseUnit>Bit</BaseUnit> 

</DataWordWidth> 

<MeasurementRef  IDREF="Time" /> 

<Syllables> 

<Syllable> 

<Name>Time  Measurement 

Sy 11 able < /Name > 

</Syllable> 

</Syllables> 

</DataWord> 

<DataStructureEieldRef 
IDREE= "Package l_Field3 "/> 

<TimeOrder>IncreasingTemporal</TimeOrder> 

</DataWordToEieldMap> 

</DataMaps> 

Note:  If  repeating  fields  are  required,  then  packages  without 
headers  can  be  used  to  create  the  same  resulting  output  as  one 
defined  by  repeating  fields.  To  accomplish  this,  the  first  package 
would  use  standard  package  headers  and  contain  a  measurement 
value  and  MeasurementTimeRef .  Subsequent  repeating 
packages  would  not  use  a  header  and  contain  the  repeated 
measurement  values  each  with  its  own  MeasurementTimeRef. 
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Acronyms 


CINR 

Carrier  to  Interference  -i-  Noise  Ratio 

DSCP 

Diffserv  Code  Point 

GHz 

gigahertz 

lOCTL 

input/output  control 

IP 

Internet  Protocol 

kHz 

kilohertz 

MAC 

media  access  control 

MDL 

Metadata  Description  Language 

RF 

radio  frequency 

RFNM 

radio  frequency  network  message 

RSSI 

received  signal  strength  indicator 

TCP 

Transmission  Control  Protocol 

TE 

Traffic  Engineering 

TAI 

International  Atomic  Time 

TLV 

T  ype-Length- V  alue 

TmNS 

Telemetry  Network  Standard 

TxOp 

transmission  opportunity 
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CHAPTER  24 


Message  Formats 

Application  messages  are  message  struetures  used  to  pass  information  between 
applications  using  an  application  layer  protoeol.  The  bit  numbering,  bit  ordering,  and  byte 
ordering  conventions  used  in  this  chapter  are  deseribed  in  Chapter  21  Appendix  21-B. 


24.1  Type-Length  Value  Structure 

The  Type-Length- Value  (TLV)  message  strueture  is  depicted  in  Figure  24-1. 


TYPE 


LENGTH 


VALUE 


Eigure  24- 1 .  Type-Length- V alue  Strueture 


The  TLV  field  descriptions  are  provided  below. 

Field  Name  Field  Length  Field  Description 

Type  Eixed  Type  of  the  TLV  message,  encoded  as  a 

binary  value 

Length  Eixed  Length,  typieally  in  bytes,  of  the  entire  TLV 

message  (including  Type  and  Length  fields) 
Value  Length  =  Length  field  Data  portion  of  the  TLV  message 

value  -  (the  length  of  the 
Type  field  -i-  length  of  the 
Length  field) 


Lor  each  defined  TLV  sequenee,  the  Type  and  Length  field  sizes  are  fixed,  a  specifie  set 
of  Types  are  defined,  and  each  Value  field  may  encode  one  or  more  pieees  of  information,  as 
depieted  in  Eigure  24-2. 


TYPE 

LENGTH 

VALUE 

Type 

Length 

Value  1 

Value2 

ValueN 

Eigure  24-2.  Multi-Value  TLL  Strueture 


NOTE 


y 


The  following  figure  represents  an  ASCII  message  “ABCD”  (0x41,  0x42, 
0x43,  0x44)  with  a  Type  of  0xA97.  The  Type  field  is  two  bytes  long  and  the 
Length  field  is  one  byte  long. 


Byte  Number 
Data 


Type 
1  2 
OxOA  0x97 


Length 

3 

0x07 


Value 
4  5 

0x41  0x42 


6 

0x43 


7 

0x44 


24.2  TmNSMessage 

A  TmNSMessage  shall  eontain  a  TmNSMessageHeader  and  may  contain  a 
TmNSMessagePayload  as  shown  in  Eigure  24-3. 
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Figure  24-3.  TmNSMessage  Structure 


All  TmNSMessageHeader  and  PackageHeader  fields  in  the  TmNSMessagePayload  shall 
use  big-endian  ordering  as  specified  in  Chapter  21  Section  B.3  and  the  bit  numbering  specified  in 
Chapter  21  Section  B.2.  TmNSMessagePayload  fields  (e.g.,  PackagePayloads  fields  described 
in  MDL  instance  documents)  are  often  based  on  acquisition  data  from  non-Internet  Protocol  (IP)- 
network  systems  and,  therefore,  are  not  required  to  comply  with  the  big-endian  convention. 


NOTE 


y 


The  IP  specification  defines  standard  network  byte  order  as  big-endian  for  all 
numeric  values  in  the  IP  packet  headers.  This  standard  maintains  consistency 
with  the  IP  specification  by  defining  all  numeric  values  in 
TmNSMessageHeader  and  PackageHeader  fields  of  the  TmNSMessage  as 
following  network  byte  order  (i.e.,  big-endian). 


24.2.1  TmNSMessageHeader  Structure 

The  TmNSMessageHeader  shall  contain  the  following  fields  and  associated  bit-widths  as 
outlined  in  Figure  24-4. 

•  MessageVersion  -  4  bits 

•  OptionWordCount  -  4  bits 

•  Reserved  -  4  bits 

•  MessageType  -  4  bits 

•  MessageFlags  -  16  bits 

•  MessageDefinitionID  -  32  bits 

•  MessageDefinitionSequenceNumber  -  32  bits 

•  MessageLength  -  32  bits 

•  MessageTimestamp  -  64  bits 

•  ApplicationDefinedFields  -  variable  (OptionWordCount  *  32  bits) 
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Figure  24-4.  TmNSMessageHeader  Structure 

24.2.1.1  MessageVersion  Field 

The  MessageVersion  field  specifies  the  version  of  the  TmNSMessage  protocol.  This 
document  defines  Message  Version  1  (i.e.,  4’bOOOl) 

24.2.1.2  OptionW ordCount  Field 

The  OptionWordCount  field  shall  specify  the  number  of  32-bit  words  in  the 

ApplicationDefinedFields . 

24.2. 1 .3  Reserved  Field 

This  field  is  reserved  for  future  use.  All  bits  shall  be  set  to  zero  (4’bOOOO)  on 
transmission;  ignored  on  reception. 

24.2.1.4  MessageType  Field 

The  MessageType  field  specifies  the  type  of  the  TmNSMessage.  This  document  defines 
the  following  message  types: 
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•  4’bOOOO  -  TmNSDataMessage 

24.2.1.5  MessageFlags  Field 

The  MessageFlags  field  shall  provide  indicators  of  TmNSMessage  options  and/or 
conditions.  Using  the  bit-numbering  convention  specified  in  Chapter  21  Appendix  21-B,  the  bits 
are  defined  as  follows. 

•  Reserved  for  Future  Use  bits  (bits  15-8).  All  bits  shall  be  set  to  zero  (8’hOO)  on 
transmission;  ignored  on  reception. 

•  StandardPackageHeaderFlag  bit  (bit  7): 

o  1  ’bO  -  At  least  one  Package  uses  a  PackageHeader  completely  described  in  an 
MDL  instance  document  or  at  least  one  Package  does  not  contain  a 
PackageHeader 

o  I’bl  -  All  Packages  use  the  Standard  PackageHeaders  (see  Subsection 
24.2.2.1.1) 

For  TniNSMessages  that  do  not  contain  Packages,  this  bit  shall  be  set  to  I’bO. 

•  PlaybackDataFlag  bit  (bit  6): 

o  1  ’bO  -  Live  data  (from  source) 
o  I’b  1  -  Playback  data 

•  MessageFragmentationFlags  bits  (bits  5-4): 

o  2’bOO  -  Complete  TmNSMessage 
o  2’bOl  -  TmNSMessage  with  the  first  fragment 
o  2’blO  -  TmNSMessage  with  a  middle  fragment 
o  2’bl  1  -  TmNSMessage  with  the  last  fragment 
See  Chapter  26  Subsection  26.5.3  for  more  details. 

•  DataSourceAcquiredDataFlag  bit  (bit  3): 

o  I’bO  -  Acquired  data  in  this  TmNSMessage 
o  I’bl  -  Simulated  data  in  this  TmNSMessage 

•  DataSourceTimeLockFlag  bit  (bit  2): 

o  I’bO  -  DataSource  time  locked  to  IEEE  1588  master  clock 
o  I’bl  -  DataSource  time  NOT  locked  to  IEEE  1588  master  clock 

•  DataSourceHealthElag  bit  (bit  1): 

o  I’bO  -  No  error  in  the  portion  of  the  DataSource  generating  this  TmNSMessage 
o  I’bl  -  Error  in  the  portion  of  the  DataSource  generating  this  TmNSMessage 

•  EndOfDataElag  bit  (bit  0) 

o  I’bO  -  Normal  TmNSMessage 
o  I’bl  -  End-of-data  TmNSMessage 
See  Chapter  26  Subsection  26.4.2.2  for  usage  details  of  this  bit. 

See  Chapter  26  Subsection  26.5.4  for  rules  governing  the  merging  of  the  MessageFlags 
field  from  multiple  TmNSDataMessages. 

24.2. 1 .6  MessageDefinitionID  Field 

The  MessageDefinitionID  field  shall  contain  the  MessageDefinitionID  of  the 
TmNSMessage. 
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24.2. 1 .7  MessageDefinitionSequenceNumber  Field 

The  MessageDefinitionSequenceNumber  field  shall  provide  a  non-negative  integer  that 
increments  by  one  for  each  TmNSMessage  instance  in  a  sequence  of  TmNSMessages. 

See  Chapter  26  Subsection  26.5.1  for  additional  MessageDefinitionSequenceNumber 

rules. 

24.2. 1 .8  MessageLength  Field 

The  MessageLength  field  shall  provide  the  length  (in  bytes)  of  the  TmNSMessage  (or 
fragment),  including  the  TmNSMessageHeader  and  TmNSMessagePayload  (including  padding). 

Padding  shall  be  used  if  a  TmNSMessage  does  not  fall  on  a  32-bit  boundary. 

24.2. 1 .9  MessageTimestamp  Field  (64  bits) 

The  MessageTimestamp  field  shall  provide  the  message  base  time  (in  seconds  and 
nanoseconds).  The  field  shall  use  the  lower  64  bits  of  the  IEEE  1588-2008  specified  time 
structure. 

See  Chapter  26  Subsection  26.5.2  for  additional  MessageTimestamp  rules. 

24.2. 1.10  ApplicationDefinedEields  Eield  (OptionWordCount*32  bits) 

ApplicationDefinedFields  provide  for  optional  header  fields  identified  by  the  option- 
kind  field  (similar  to  Transmission  Control  Protocol  [TCP]  Options).  Eigure  24-5  shows 

ApplicationDefinedFields . 


Field  Name 


option-kind 

option-length 

option-data 


Field  Lensth 

1  byte 
1  byte 

0  to  58  bytes 


Field  Description 

Indicates  type  of  optional  field 

Indicates  length  in  bytes  of  particular  option  field 

+  2  bytes  for  the  kind  and  length  fields 

Data  associated  with  a  particular  option  field 


* -  option-length  -  option-data  length  +  2  bytes 

TLV  Type 

TLV  Length 

TLV  Value 

option-kind 
(1  bjte) 

option-length 
(1  byte) 

option-data 
(0  to  58  bytes) 

Figure  24-5.  Option-Kind  Message  Structure 


Multiple  option-kind  fields  may  be  included  in  the  ApplicationDefinedFields  as 
long  as  the  total  ApplicationDefinedFields  size  does  not  exceed  60  bytes.  The 
ApplicationDefinedFields  shall  fall  on  a  32-bit  boundary  (i.e.,  length  shall  be  an  integer  number 
of  32-bit  words).  For  option-kind  values  between  8’hOO  -  8’h7F  inclusive,  neither  the 
option-length  nor  option-data  fields  are  included  resulting  in  a  length  of  one  byte.  For 
option-kind  values  between  8’h80  -  8’hFF  inclusive,  both  the  option-length  and 
option-data  fields  are  included,  resulting  in  an  option-data  length  of  option- 
length  -  2  bytes.  Table  24-1  defines  each  supported  option-kind  value  along  with  their 
corresponding  option-length  and  option-data  values. 
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Table  24-1.  ApplicationDefinedFields  “option-kind”  List 

option- 

kind 

Type 

option- 

length 

option-data 

Comment 

8’hOO 

End  of 

Options 

N/A 

N/A 

Also  used  for  padding  to 
32-bit  boundary 

8’hOl 

No  Operation 
(NOP) 

N/A 

N/A 

Allows  individual  options 
to  be  32-bit  aligned  if 
needed  (not  required) 

8’h02  - 
8’h3F 

N/A 

N/A 

Reserved  for  future 
allocation 

8’h40  - 
8’h7F 

N/A 

N/A 

Reserved  for 
implementation-specific 
or  experimental  use 

8’h80 

Reserved  for  future 
allocation 

8’h81 

Reserved  for  future 
allocation 

8’h82 

DataSource 

Configuration 

3-32 

An  implementation-specific 
structure  of  configuration  for 
the  DataSource  generating 
this  TmNSDataMessage 

8’h83 

DataSource 

Error 

3-32 

An  implementation-specific 
structure  of  an  error  condition 
for  the  DataSource  generating 
this  TmNSDataMessage 

8’h84 

Reserved  for  future 
allocation 

8’h85 

Destination 

Address 

6 

18 

IPv4  address  (unicast, 
multicast,  broadcast) 

IPv6  address  (unicast, 
multicast,  broadcast) 

8’h86 

Eragment 

Byte  Offset 

6 

Byte  offset  of  current 
fragment  (32-bit  length) 

8’h87 

Package 

Count 

6 

Count  of  number  of  Packages 
in  this  message 

8’h88 

Ingress 

Timestamp 

8 

Timestamp  of  when  a 
message  was  most  recently 
received.  Timestamp  format 
is  32-bit  International  Atomic 
Time  (TAI)  seconds  field 
followed  by  32-bit 
nanoseconds  field. 

This  is  the  system  time 
when  the  receiving  entity 
received  this  message. 
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Table  24-1.  ApplicationDefinedFields  “option-kind”  List 

option- 

kind 

Type 

option- 

length 

option-data 

Comment 

8’h89 

Egress 

Timestamp 

8 

Timestamp  of  when  a 
message  was  most  recently 
transmitted.  Timestamp 
format  is  32-bit  TAI  seconds 
field  followed  by  32-bit 
nanoseconds  field. 

This  is  the  system  time 
when  the  transmitting 
entity  sent  the  message 
(e.g.,  local  system  time  of 
recorder  when  it  sends  a 
message  it  received 
previously). 

8’h8A 

-8’hBF 

Reserved  for  future 
allocation 

8’hCO 
-  8’hFF 

Reserved  for 
implementation-specific 
or  experimental  use 

NOTE 


The  use  of  ApplicationDefinedFields’  option-kind  value  in  the 
“implementation- specific  or  experimental  use”  range  is  permitted  but  does  not 
ensure  interoperability. 


24.2.2  TmNSMessagePayload  Structure 

The  TmNSMessagePayload  is  optional.  If  present,  the  TmNSMessagePayload  shall 
include  one  or  more  Packages  as  illustrated  in  Figure  24-6. 


Figure  24-6.  TmNSDataMessagePayload  Structure 


NOTE 


y 


The  MessageDefinitionID  specified  in  the  TmNSDataMessage  header 
serves  as  a  reference  to  the  structure,  content,  and  ordering  of  Package(s) 
in  the  TmNSDataMessage  payload.  For  details  on  how  this  information 
is  described  within  an  MDL  instance  document,  refer  to  Chapter  23. 


Each  Package  shall  include  either  a  PackageHeader,  a  Package  Payload,  or  both.  The 
case  where  both  a  PackageHeader  and  PackagePayload  are  present  is  illustrated  in  Figure  24-7. 
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S 

Package 

\  \ 

V 

PackageHeader 

PackagePayload 

Figure  24-7.  Package  Structure  Containing  PackageHeader  and 

PackagePayload 


24 . 2 . 2 . 1  Package  Header 

The  PackageHeader  contains  fields  that  describe  the  PackagePayload.  When  using  a 
PackageHeader,  TmNSDataMessages  shall  use  either  the  standard  PackageHeader  or  a 
PackageHeader  completely  described  in  an  MDL  instance  document. 

24.2.2.1.1  Standard  PackageHeader 

The  standard  PackageHeader  shall  contain  the  following  fields. 

•  PackageDefinitionID  -  32  bits 

•  PackageLength  -  16  bits 

•  Reserved  -  8  bits 

•  PackageStatusFlags  -  8  bits 

•  PackageTimeDelta  -  32  bits 

Figure  24-8  illustrates  the  standard  PackageHeader.  When  using  standard 
PackageHeaders,  the  Package  shall  start  and  end  on  32-bit  boundaries. 
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Figure  24-8.  Standard  PackageHeader  Field  Structure 

1.1. 1.1. 1.1.1  PackageDefinitionID  Field 

The  PackageDefinitionID  field  shall  contain  the  PackageDefinitionID  of  the  Package. 

1.1. 1.1. 1.1. 2  PackageLength  Field 

The  PackageLength  field  shall  specify  the  length,  in  bytes,  of  the  entire  Package 
(including  PackageHeader  and  PackagePayload,  but  not  including  padding)  to  identify  the  end 
of  bytes  containing  MeasurementData  in  the  Package. 

Padding  shall  be  used  to  ensure  a  Package  with  a  standard  PackageHeader  starts  and 
ends  on  a  32-bit  boundary. 

1.1. 1.1. 1.1. 3  Reserved 

All  bits  shall  be  set  to  zero  (8’hOO)  on  transmission;  ignored  on  reception. 

1.1. 1.1. 1.1. 4  PackageStatusFlags  Field 

The  PackageStatusFlags  field  may  provide  indications  on  specific  MeasurementData  in 
a  Package  and/or  error  indications  (e.g.,  parity,  out  of  range,  wrong  frame  size,  etc.)  of  the 
DataSource  producing  the  MeasurementData.  These  flags  can  be  described  by  an  MDL  instance 
document.  Each  PackageStatusFlags’  I’bO  value  shall  be  interpreted  as  a  “no  error”  condition 
for  that  particular  condition.  Each  PackageStatusFlags  bit  not  described  in  an  MDL  instance 
document  shall  be  set  to  I’bO. 

1.1. 1.1. 1.1. 5  PackageTimeDelta  Field 

The  PackageTimeDelta  field  shall  provide  the  Package  base  time  relative  to  the 
MessageTimestamp  field  in  the  TmNSDataMessageHeader.  The  value  in  the  field  shall  be  a 
non-negative  integer  that  represents  nanosecond  resolution  in  the  range  of  0  to  2^^  -  1 . 
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24.2.2.1.2  MDL-Described  PackageHeader 

A  custom  PackageHeader  shall  be  used  if  the  standard  PackageHeader  is  not  used  for 
the  Package.  Custom  PackageHeaders  shall  be  completely  described  within  the  MDL  instance 
document  that  contains  the  Package  description. 

24.2.2.2  Package  Time  Measurement  Scoping  Rules 

The  Telemetry  Network  Standard  (TmNS)  schema  in  Chapter  23  defines  the 
MeasurementTimeRef  element,  which  is  a  measurement  that  is  associated  with  another 
measurement.  There  shall  be  no  MeasurementTimeRef  elements  that  reference  outside  a  single 
package  instance  within  a  single  message  instance. 

24.3  Radio  Frequency  (RF)  Network  Message 

There  is  one  general  structure  for  all  RF  network  messages.  The  structure  consists  of  a 
common  RF  network  message  header  followed  by  the  RF  network  message  payload.  The 
payload  consists  of  one  or  more  TLVs. 


Figure  24-9.  RF  Network  Message  Structure 


All  fields  in  an  RF  network  message  shall  use  big-endian  ordering  as  specified  in  Chapter 
21  Appendix  21-B. 

24.3.1  RF  Network  Message  Header  Structure 

An  RF  network  message  header  shall  contain  the  following  fields  shown  in  Figure  24-10: 

•  Message  Length  -  16  bits 

•  Destination  RF  Media  Access  Control  (MAC)  address  -  16  bits 

•  Souree  RF  MAC  Address  -  16  bits 

•  Message  Sequence  Number  -  32  bits 
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Figure  24-10.  RF  Network  Message  Header  Strueture 


24.3.1.1  Message  Length 

This  field  indieates  the  remaining  length  in  bytes  of  the  RF  network  message.  The  size  of 
the  RF  network  message  is  the  size  of  the  Message  Length  field  plus  the  value  contained  therein. 


24.3. 1 .2  Destination  RF  MAC  Address 

This  field  contains  the  destination  RF  MAC  address.  The  combination  of  the  destination 
RF  MAC  address  and  the  source  RF  MAC  address  identify  a  particular  link  for  which  the  RF 
network  message  is  associated 


24.3.1.3  Source  RF  MAC  Address 

This  field  contains  the  source  RF  MAC  address. 


24.3. 1 .4  Message  Sequence  Number 

The  Message  Sequence  Number  serves  as  an  identifier  of  a  particular  RF  network 
message.  The  sequence  number  shall  be  associated  with  the  destination  RF  MAC  address  and 
source  RF  MAC  address  pair  contained  in  the  RF  network  message  header.  Entities  that  send  RF 
network  messages  shall  increment  the  sequence  number  associated  with  a  particular  destination 
RF  MAC  address  and  source  RF  MAC  address  pair  after  each  RF  network  message  is  generated. 

This  value  shall  be  initialized  with  32’dO.  The  first  RF  network  messages  produced  for  a 
particular  destination  RF  MAC  address  and  source  RF  MAC  address  pair  shall  be  32’dO. 

24.3.2  RF  Network  Message  Payload  Structure 

The  RF  network  message  (RFNM)  payload  consists  of  one  or  more  TLV  structures.  The 
defined  TLVs  are  contained  in  Table  24-2. 
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Table  24-2.  RF  Network  Message  TLVs 

TLV 

Type 

Descriptions 

Transmission 

Opportunity 

(TxOp) 

Assignment 

1 

This  TLV  is  used  by  the  time-division  multiple  access 
scheduler  to  allocate  a  transmission  opportunity  on  a  radio 
link. 

TxOp  ID 

Aeknowledgement 

Report 

2 

This  TLV  is  used  by  a  radio  to  report  the  acknowledgement 
of  specific  TxOps  that  have  been  received  and  processed 
and  applied  to  the  active  schedule. 

MAC  Queue 

Status  Report 

3 

This  TLV  is  used  by  a  radio  to  report  MAC  layer  queue 
level. 

Heartbeat 

5 

This  TLV  is  used  to  establish  a  timeout  value  used  by  the 
radio  to  classify  TxOps  received  from  RF  link  management 
as  stale. 

Link  Metric 

6 

This  TLV  contains  an  absolute  time  (converted  to  an 
internal  representation)  and  link  metric  measurements 
pertaining  to  a  specific  radio  link. 

TE  Queue  Status 
Report 

10 

This  TLV  is  used  by  a  radio  to  report  Traffic  Engineering 
(TE)  queue  levels  for  each  of  the  8  TE  queues  associated 
with  a  particular  link  on  the  reporting  radio. 

Link  Transmit 
Statistics  Report 

11 

This  TLV  contains  the  count  of  IP  packets  transmitted  over 
the  specified  RF  link. 

24.3.2.1  TxOp  Assignment  TLV 


The  TxOp  Assignment  TLV  shall  be  used  to  alloeate  transmission  opportunities  on  a 
radio  for  the  link  eomprised  of  the  destination  RF  MAC  address  and  souree  RF  MAC  address  in 
the  RF  network  message  header.  The  TxOp  Assignment  TLV  is  deseribed  in  Table  24-3. 


Table  24-3.  TxOp  Assignment  TLV 

Field 

Width  (bits) 

Descriptions 

Value/Range 

Type 

8 

Type:  Transmission  Opportunity  Assignment 

1 

Length 

8 

Length  in  bytes 

13 

Center 

Frequency 

16 

Carrier  or  operating  frequency  given  in  units  of 
250  kilohertz  (kHz)  (up  to  16  gigahertz  [GHz]) 

[0,  2^6-1] 

Reserved 

8 

This  field  is  reserved  for  future  use.  The  value 
shall  be  set  to  8’h80. 

8’h80 

TxOp  ID 

16 

An  identifier  for  the  TxOp.  If  the  value  of  this 
field  is  set  to  zero  (16’h0000),  no 
acknowledgement  for  the  TxOp  will  be 
provided  through  the  TxOp  ID  Ack  Report 

TLV. 

[0,  216-1] 
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Table  24-3.  TxOp  Assignment  TLV 

Field 

Width  (bits) 

Descriptions 

Value/Range 

TxOp 

Timeout 

8 

The  value  specifying  the  number  of 
consecutive  epochs  for  which  this  transmission 
opportunity  is  valid.  Additionally,  the  value  of 
8’hO  is  reserved  to  indicate  that  any  existing 
TxOp  with  a  non-zero  remaining  timeout  value 
whose  interval  is  wholly  contained  by  Start 
and  Stop  Subseconds  field  of  this  message  is 
deleted  from  all  future  epochs.  The  value  of 
8’hFF  is  reserved  to  indicate  that  this  TxOp 
has  an  infinite  lifetime  and  will  remain  in 
effect  until  explicitly  deleted  or  until  the 
transmission  heartbeat  times  out. 

[0,  255] 

TxOp  Start 
Subseconds 

20 

The  value  specifying  the  fractional  sub¬ 
seconds  portion  of  a  TxOp  start  time,  measured 
in  microseconds  relative  to  the  start  of  the 
epoch. 

[0,  999,999] 

TxOp  Stop 
Subseconds 

20 

The  value  specifying  the  fractional  sub¬ 
seconds  portion  of  a  TxOp  stop  time,  measured 
in  microseconds  relative  to  the  start  of  the 
epoch. 

[0,  1,000,000] 

24.3.2.2  TxOp  ID  Acknowledgement  Report  TLV 

The  TxOp  ID  Acknowledgement  Report  TLV  shall  be  used  to  deliver  one  or  more  ID 
values  of  TxOps  that  have  been  applied  to  the  transmission  schedule  of  the  transceiver.  This 
TLV  is  not  directly  accountable  to  the  link  identified  in  the  RFNM  header  of  the  message 
containing  this  TLV,  thus  a  single  RFNM  may  contain  ID  values  from  TxOps  that  were  supplied 
to  different  links  on  the  transceiver.  Any  TxOps  whose  ID  value  is  set  to  zero  (16’hOOOO)  shall 
not  be  acknowledged.  The  TxOp  ID  Acknowledgement  Report  TLV  is  described  in  Table  24-4. 


Table  24-4.  TxOp  ID  Acknowledgement  Report  TLV 

Field 

Width  (bits) 

Descriptions 

Value/Range 

Type 

8 

Type:  TxOp  ID  Ack  Report 

2 

Length 

8 

Length  in  bytes 

2-I-2N,  where  ‘N’  is  the 
number  of  TxOpIds 
being  acknowledged  in 
this  TLV 

TxOp  ID  1 

16 

The  TxOp  ID  of  the  first  TxOp  being 
acknowledged  in  this  TLV.  Required. 

[1,  2*^-1] 

...  Optional. 

TxOp  ID  N 

16 

The  TxOp  ID  of  the  Nth  TxOp  being 
acknowledged  in  this  TLV.  Optional. 

[1,  2*^-1] 
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24.3.2.3  MAC  Queue  Status  Report  TLV 

The  MAC  Queue  Status  Report  TLV  shall  be  used  to  report  the  MAC  layer  queue  level 
of  the  radio  for  the  link  comprised  of  the  destination  RF  MAC  address  and  source  RF  MAC 
address  in  the  RF  network  message  header.  The  MAC  Queue  Status  Report  TLV  is  described  in 
Table  24-5. 


Table  24-5.  MAC  Queue  Status  Report  TLV 

Field 

Width  (bits) 

Descriptions 

Value/Range 

Type 

8 

Type:  MAC  Queue  Status  Report 

3 

Length 

8 

Length  in  bytes 

8 

Reserved 

2 

Reserved 

2’bOO 

Timestamp 

Seconds 

6 

The  value  specifying  the  seconds  portion  of  a 
timestamp  of  when  the  MAC  Queue  Status  was 
sampled,  measured  in  seconds  and 
corresponding  to  the  least  significant  6  bits  of 
the  seconds  portion  of  TAI  time. 

[0,  63] 

Reserved 

4 

Reserved 

4’bOOOO 

Timestamp 

Subseconds 

20 

The  value  specifying  the  fractional  sub-seconds 
portion  of  when  the  MAC  Queue  Status  was 
sampled,  measured  in  microseconds  relative  to 
the  timestamp  Seconds  field. 

[0,  999,999] 

MAC  Queue 
Level 

16 

Amount  of  data  (reported  in  units  of  64  bytes, 
rounded  up)  buffered  in  transceiver,  pending 
transmission 

[0,  2*^-1] 

24.3.2.4  Heartbeat  TLV 


The  Heartbeat  TLV  shall  be  used  to  deliver  an  updated  transmission  heartbeat  to  a  radio. 
The  Heartbeat  TLV  is  described  in  Table  24-6. 


Table  24-6.  Heartbeat  TLV 

Field 

Width  (bits) 

Descriptions 

Value/Range 

Type 

8 

Type:  Heartbeat 

5 

Length 

8 

Length  in  bytes 

4 

Timeout 

16 

Number  of  future  epochs  that  this  radio  is 
authorized  to  execute  TxOps.  The  value  of  65,535 
(16’hFFFF)  is  reserved  to  indicate  a  heartbeat  that 
has  an  infinite  lifetime  and  will  remain  in  effect 
until  explicitly  changed. 

[0,  2*^-1] 

24.3.2.5  Link  Metric  TLV 

The  Link  Metric  TLV  shall  be  used  to  deliver  receiver  statistics  for  the  link  comprised  of 
the  destination  RF  MAC  address  and  source  RF  MAC  address  in  the  RF  network  message 
header.  The  Link  Metric  TLV  is  described  in  Table  24-7. 
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Table  24-7.  Link  Metric  TLV 

Field 

Width  (bits) 

Descriptions 

Value/Range 

Type 

8 

Type 

6 

Eength 

8 

Eength  in  bytes 

15 

Timestamp 

32 

The  time  that  this  snapshot  of  Eink  Metric 
information  was  taken.  This  timestamp  format 
consists  of  the  following  three  subfields: 

Bits  31-26  -  Reserved 

Bits  25-20  -  seconds 

Time,  in  seconds,  when  snapshot  was  taken, 
corresponding  to  the  least-significant  6  bits  of 
the  seconds  portion  of  TAI  time 

Bits  19-0  -  microseconds 

The  fractional  sub-second  portion  of  the 
timestamp,  measured  in  microseconds. 

6’bOOOOOO 

[0-63] 

[0-999,999] 

Center 

frequency 

16 

Indicates  the  center  frequency  where 
measurements  are  made.  The  center  frequency 
is  given  in  units  of  250  kHz  (up  to  16  GHz) 

[0,  2*^-1] 

RSSI 

8 

Received  signal  strength  indicator.  This  is  a  2’s 
compliment  signed  integer  indicating  the  RSSI 
in  I -dBm  step  with  a  maximum  range  of  -127 
dBm  to  127  dBm.  The  field  is  assigned  -128 
(hex  0x80)  when  RSSI  measurement  is  not 
available. 

[-128,  127] 

CINR 

8 

Carrier  to  Interference  -i-  Noise  Ratio.  This  is  a 
2’s  compliment  signed  integer  indicating  the 
CINR  in  I-dB  step  with  a  maximum  range  of 
-127  dB  to  127  dB.  The  field  is  assigned  -128 
(hex  0x80)  when  CINR  measurement  is  not 
available. 

[-128,  127] 

Average 
channel  bit 

error  rate 

8 

This  is  an  unsigned  integer  indicating  the 
channel  error  rate  in  units  of  1/2^  with  a  range  of 
1/2^  to  1-1/2*.  The  field  is  assigned  0  when 
channel  bit  error  rate  measurement  is  not 
available. 

[0,  2*-l] 

Received 

IP  Packet 
Count 

32 

The  number  of  IP  packets  that  have  been 
received  over  the  RE  link  identified  by  the 

RENM  header. 

[0,  2*2-1] 

24.3.2.6  Traffic  Engineering  Queue  Status  Report  TLV 

The  TE  Queue  Status  Report  TEV  shall  be  used  to  report  the  queue  levels  of  the  eight 
different  TE  queues  of  the  radio  for  the  link  comprised  of  the  destination  RE  MAC  address  and 
source  RE  MAC  address  in  the  RE  network  message  header.  The  TE  Queue  Status  Report  TEV 
is  described  in  Table  24-8. 
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Table  24-8.  TE  Queue  Status  Report  TLV 

Field 

Width  (bits) 

Descriptions 

Value/Range 

Type 

8 

Type:  TE  Queue  Status  Report 

10 

Length 

8 

Length  in  bytes 

27 

Reserved 

2 

Reserved 

2’bOO 

Timestamp 

Seconds 

6 

The  value  specifying  the  seconds  portion  of 
a  timestamp  of  when  the  TE  Queue  Status 
was  sampled,  measured  in  seconds  and 
corresponding  to  the  least  significant  6  bits 
of  the  seconds  portion  of  TAI  time. 

[0,  63] 

Reserved 

4 

Reserved 

4’bOOOO 

Timestamp 

Subseconds 

20 

The  value  specifying  the  fractional  sub¬ 
seconds  portion  of  when  the  TE  Queue 

Status  was  sampled,  measured  in 
microseconds  relative  to  the  timestamp 
Seconds  field. 

[0,  999,999] 

MSLPID 

32 

Identifier  for  the  mission  service-level 
profile  associated  with  this  radio  link 

[0,  2^2-1] 
Default:  0 

Version 

8 

Unique  identifier  for  this  specific  queue 
status  report:  TE  Queue  depth 

0 

DSCP  Class  0 
Queue  Level 

16 

Amount  of  data  (reported  in  units  of  64 
bytes,  rounded  up)  in  the  queue(s)  for 

Diffserv  Code  Point  (DSCP)  Class  0  (DSCP 
values  0  to  7) 

[0,  2*^-1] 

DSCP  Class  1 
Queue  Level 

16 

Amount  of  data  (reported  in  units  of  64 
bytes,  rounded  up)  in  the  queue(s)  for  DSCP 
Class  1  (DSCP  values  8  to  15) 

[0,  2'®-l] 

DSCP  Class  2 
Queue  Level 

16 

Amount  of  data  (reported  in  units  of  64 
bytes,  rounded  up)  in  the  queue(s)  for  DSCP 
Class  2  (DSCP  values  16  to  23) 

[0,  2^'>-l] 

DSCP  Class  3 
Queue  Level 

16 

Amount  of  data  (reported  in  units  of  64 
bytes,  rounded  up)  in  the  queue(s)  for  DSCP 
Class  3  (DSCP  values  24  to  31) 

[0,  2*^-1] 

DSCP  Class  4 
Queue  Level 

16 

Amount  of  data  (reported  in  units  of  64 
bytes,  rounded  up)  in  the  queue(s)  for  DSCP 
Class  4  (DSCP  values  32  to  39) 

[0,  2*^-1] 

DSCP  Class  5 
Queue  Level 

16 

Amount  of  data  (reported  in  units  of  64 
bytes,  rounded  up)  in  the  queue(s)  for  DSCP 
Class  5  (DSCP  values  40  to  47) 

[0,  2^'>-l] 

DSCP  Class  6 
Queue  Level 

16 

Amount  of  data  (reported  in  units  of  64 
bytes,  rounded  up)  in  the  queue(s)  for  DSCP 
Class  6  (DSCP  values  48  to  55) 

[0,  2'®-l] 

DSCP  Class  7 
Queue  Level 

16 

Amount  of  data  (reported  in  units  of  64 
bytes,  rounded  up)  in  the  queue(s)  for  DSCP 
Class  7  (DSCP  values  56  to  63) 

[0,  2'®-l] 
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24.3.2.7  Link  Transmit  Statistics  Report  TLV 

The  Link  Transmit  Statistics  Report  TLV  shall  be  used  to  report  the  number  of  IP  packets 
transmitted  by  the  transmitter  over  the  link  comprised  of  the  destination  and  source  RF  MAC 
address  in  the  RF  network  message  header.  Table  24-9  describes  the  specifics  of  the  link 
transmit  statistics. 


Table  24-9.  Link  Transmit  Statistics  Report  TLV 

Field 

Width  (bits) 

Description 

Value/Range 

Type 

8 

Type 

Length 

8 

Length  in  bytes 

Timestamp 

32 

The  time  that  this  snapshot  of  link  transmission 
statistics  was  taken.  This  timestamp  format 
consists  of  the  following  three  subfields. 

Bits  31-26  -  reserved 

6’bOOOOOO 

Bits  25-20  -  seconds 

Time,  in  seconds,  when  snapshot  was  taken, 
corresponding  to  the  least-significant  6  bits  of 
the  seconds  portion  of  TAI  time. 

[0-63] 

Bits  19-0  -  microseconds 

The  fractional  sub- second  portion  of  the 
timestamp,  measured  in  microseconds 

[0-999,999] 

Transmitted 
IP  Packet 
Count 

32 

The  number  of  IP  packets  that  have  been 
transmitted  over  the  RF  link  identified  by  the 
RFNM  header. 

[0,  232-1] 

24.4  TSS  Messages 

TmNS  Source  Selector  (TSS)  functionality  is  described  in  Chapter  28,  but  the  TSS 
messages  are  defined  in  this  section.  The  TSS  messages  shall  be  exchanged  between  TSS 
interfaces.  There  are  two  types  of  TSS  messages  defined: 

•  TSS  Initialization  Message 

•  TSS  Data  Message 

24.4.1  TSS  Initialization  Message  Structure 

After  initial  TCP  socket  connection  is  established,  the  TSS  server  (e.g.,  typically  a  radio) 
shall  send  6  TSS  initialization  messages.  The  TSS  initialization  message  structure  shall  contain 
the  following  fields  as  shown  in  Figure  24-11. 

•  Interface  Parameter  Identifier  -  4  bytes 

•  Interface  Parameter  -  32  bytes 
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Figure  24-11.  TSS  Initialization  Message  Strueture 


24.4. 1 . 1  Interface  Parameter  Identifier 

The  Interface  Parameter  Identifier  field  shall  contain  one  of  the  six  values  shown  in  Table 
24-10.  These  values  have  been  chosen  to  match  Linux  input/output  control  (lOCTL)  names  that 
are  shown  so  as  to  ease  Linux  implementations.  The  six  TSS  initialization  messages  shall  be 
sent  in  the  order  shown  in  Table  24-10. 


Table  24-10.  TSS  Initialization  Message  Codes 

lOCTL  Name 

Description 

Value 

SIOCSIEHWADDR 

MAC  address  of  the  interface 

32’h00008924 

SIOCSIEMTU 

Maximum  transfer  unit  of  the  interface 

32’h00008922 

SIOCSIEADDR 

Interface  IP  address  of  the  interface 

32’h00008916 

SIOCSIEDSTADDR 

Destination  IP  address  of  the  interface  when 
point  to  point 

32’h00008918 

SIOCSIEBRDADDR 

Broadcast  IP  address  for  the  interface 

32’h0000891a 

SIOCSIENETMASK 

Network  mask  for  the  interface 

32’h0000891c 

24.4. 1 .2  Interface  Parameter 

The  Interface  Parameter  field  shall  contain  the  value  associated  with  the  parameter. 

24.4.2  TSS  Data  Message  Structure 

A  TSS  data  message  is  a  wrapper  used  to  aid  specialized  routing  of  network  traffic 
between  TmNS  networks  over  other  networks.  The  structure  of  a  TSS  data  message  is  shown 
shall  contain  the  following  fields  as  shown  in  Figure  24-12. 

•  Message  Length  -  16  bits 

•  Cyclic  Redundancy  Check  (CRC)  -  32  bits 

•  Encapsulated  Ethernet  Erame  -  variable  length 


24-18 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  24,  July  2017 


Figure  24-12.  TSS  Data  Message  Structure 


24.4.2. 1  Message  Length 

This  field  indicates  the  remaining  length  in  bytes  of  the  TSS  data  message.  The  size  of 
the  TSS  data  message  is  the  size  of  the  Message  Length  field  plus  the  value  contained  therein. 

24.4.2.2  Cyclic  Redundancy  Check  (CRC) 

The  CRC  field  of  the  TSS  data  message  serves  as  a  message  identifier  for  the  TSS  data 
message.  The  CRC  calculation  is  performed  on  the  entire  Encapsulated  Ethernet  Erame  of  the 
message,  with  the  result  being  stored  in  this  field. 

The  polynomial  to  be  used  for  CRC  calculation  shall  be  32’h82608edb. 

The  algorithm  for  the  CRC  calculation  shall  be  equivalent  to  that  shown  in  Eigure  24-13. 
The  constant  POEY  is  defined  as  the  polynomial  listed  above. 
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/# —  get_crcByte  -  perform  byte  calculations  for  CRC  process 

/#__ - - - - - - - - - 

static  inline  uint32_t  get_crcByte( int  input) 

{ 

uint32_t  val  =  input; 
int  i; 

for  (i=0;  i<8;  i++) 

{ 

if  (val  &  1) 

val  =  (val  »  1)  ^  POLY; 
else  val  »=  1; 

} 

return  val; 

} 


/* - */ 

/* —  get_crc32  -  calculate  the  32-bit  CRC  of  the  provided  buffer  — */ 

/Mf - — ^ — - - - - — - — — «■ — — - — — — */ 

static  inline  uint32_t  get_crc32{unsigned  char  *data,  int  sz) 

{ 

uint32_t  remainder,  tl,  t2; 
int  bytes; 

remainder  =  0; 

for  (bytes  =  0;  bytes  <  sz;  bytes++) 

{ 

tl  =  (remainder  »  8)  &  0X00FFFFFFL; 

t2  =  get_crcByte(  ( (int)  remainder*'(*(data+bytes) )  )&0xFF) ; 
remainder  =  tl'^t2; 

} 

for  (bytes  =  0;  bytes  <  sizeoft remainder) ;  bytes++) 

{ 

tl  =  (remainder  »  8)  &  0X00FFFFFFL; 
t2  =  get_crcByte( ( (int) remainder)&0xFF) ; 
remainder  =  tl''t2; 

} 

return  remainder; 

Figure  24-13.  Algorithm  For  CRC  Calculation  (ANSI  C  Grammar) 


— ♦/ 
- #/ 


NOTE 


A  reference  implementation  of  TSS  interfaces  and  functionality  is 
available  here. 


24.4.2.3  Encapsulated  Ethernet  Frame  (Variable  Length) 

The  Encapsulated  Ethernet  Frame  field  encapsulates  an  entire  Ethernet  frame  so  that  it 
can  be  reproduced  after  transport. 
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CHAPTER  25 

Management  Resources 


25.1  General 

Each  Telemetry  Network  Standard  (TmNS)  manageable  application  (TMA)  defines  a  set 
of  management  resources,  each  of  which  defines  application-specific  data  accessible  via  an 
application  layer  protocol.  The  term  “management  resources”  is  used  throughout  this  document 
to  describe  resources  that  can  be  managed  by  managers.  All  TmNS-specific  management 
resources  reside  within  the  TmNS  management  resources  hierarchy,  which  is  defined  here. 
Additionally,  TmNS  components  may  be  required  to  provide  host  management  resources.  In  all 
cases,  management  resources  are  used  to  provide  a  uniform  and  interoperable  method  for 
managing  components  and  aspects  of  the  TmNS  system.  There  are  two  primary  protocols  for 
accessing  the  management  resources:  Simple  Network  Management  Protocol  (SNMP)  and 
Hypertext  Transfer  Protocol  (HTTP),  which  uses  a  RESTful  architecture. 

The  TmNS-specific  management  resources  are  maintained  in  this  spreadsheet.  The 
spreadsheet  provides  a  simple  interface  for  maintaining  each  of  the  individual  management 
resources.  Each  row  in  the  spreadsheet  describes  a  different  management  resource.  The 
spreadsheet  can  be  used  to  generate  an  ASN.l -formatted  text  file  that  serves  as  the  TmNS 
management  information  base  (MIB)  (TMNS-MIB)  for  SNMP  application.  The  spreadsheet 
contains  additional  mapping  information,  such  as  uniform  resource  names  (URNs),  for  support 
of  other  management  protocols. 

25.2  Structure  of  Management  Resources 

The  structure  of  management  resources  is  hierarchical.  The  TmNS-specific  management 
resources  are  defined  in  detail  in  this  standard.  Additional  management  resources  are  defined 
through  references  to  pre-existing  Requests  for  Comment  (RECs).  As  a  matter  of 
interoperability,  the  hierarchy  of  pre-existing  RECs  is  used  in  an  unmodified  fashion. 

25.2.1  Public  REC-Based  Management  Resources 

25.2.1.1  Public  RPC  Management  Information  Base  Support 

Several  management  resources  at  the  host  level  are  defined  in  public  RPC  MIBs.  The 
TMAs  that  implement  NetworkNode  management  capabilities  shall  provide  the  following  host- 
level  management  resources: 

•  SNMPv2-MIB  (RPC  3418,  Management  Information  Base  [MIB]  for  the  Simple 
Network  Management  Protocol  [SNMP]*)  snmpBasicComplianceRev2 

•  IP-MIB  (RPC  2863,  The  Interfaces  Group  MIB  ^)  ifCompliance3 


'  Internet  Engineering  Task  Force.  “Management  Information  Base  (MIB)  for  the  Simple  Network  Management 
Protocol  (SNMP).”  RFC  3418.  December  2002.  May  be  superseded  or  amended  by  update.  Retrieved  8  May 
2017.  Available  at  httt)s://datatracker.ietf  org/doc/rfc3418/. 

^  Internet  Engineering  Task  Force.  “The  Interface  Group  MIB.”  RFC  2863.  June  2000.  May  be  superseded  or 
amended  by  update.  Retrieved  8  May  2017.  Available  at  https://datatracker.ietf.org/doc/rfc2863/. 


25-1 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  25,  July  2017 


•  IP-MIB  (RFC  4293,  Management  Information  Base  for  the  Internet  Protocol  [IP]^) 
ipMIBCompliance2 

•  TCP-MIB  (RFC  4022,  Management  Information  Base  for  the  Transmission  Control 
Protocol  [TCP]^)  tcpMIBCompliance2 

•  UDP-MIB  (RFC  41 13,  Management  Information  Base  for  the  User  Datagram 
Protocol  [UDP]  udpMIBCompliance2 

25.2.1.2  Public  RFC  Management  Information  Base  Support  for  Network  Fabric  Devices 

Network  fabric  devices  shall  implement  the  dot IdTpFdbT able  defined  in  RFC  4188^  in 
order  to  provide  layer- 2  topology  information. 

Network  fabric  devices  with  static  multicast  routing  capabilities  shall  implement  the 
dotldStaticGroup  defined  in  RFC  4188  to  provide  configuration  for  the  assignment  of  ports  to 
multicast  addresses: 

25.2.1.3  Notifications  Support 

All  TMAs  shall  be  capable  of  generating  SNMP  notifications.  All  TMAs  shall  implement 
the  following  MIB  groups: 

•  SNMP-TARGET-MIB::snmpTargetBasicGroup 

•  SNMP-TARGET -MIB : :  snmpT  argetResponscGroup 

•  SNMP-TARGET -MIB : :  snmpT  argetCommandResponderGroup 

•  SNMP-NOTIEIC  ATION-MIB : :  snmpNotifyGroup 

•  SNMP-NOTIEICATION-MIB::snmpNotifyEilterGroup 

Related  RECs:  REC  3413:  Simple  Network  Management  Protocol  (SNMP)  Applications’ 

25.2.1.4  Table  Management  using  the  RowStatus  Column 

All  TMAs  that  include  tables  with  a  RowStatus  column  shall  implement  the  RowStatus 
column  operation  in  accordance  with  RPC  2579.^ 


^  Internet  Engineering  Task  Force.  “Management  Information  Base  for  the  Internet  Protocol  (IP).”  RFC  4293. 

April  2006.  May  be  superseded  or  amended  by  update.  Retrieved  8  May  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc4293/. 

^  Internet  Engineering  Task  Force.  “Management  Information  Base  for  the  Transmission  Control  Protocol  (TCP).” 
RFC  4022.  May  be  superseded  or  amended  by  update.  Retrieved  8  May  2017.  Available  at 
https  ://datatracker.  ietf  org/doc/rfc4022/. 

^  Internet  Engineering  Task  Force.  “Management  Information  Database  for  the  User  Datagram  Protocol  (UDP).” 
RFC  41 13.  May  be  superseded  or  amended  by  update.  Retrieved  8  May  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc41 13/. 

®  Internet  Engineering  Task  Force.  “Definitions  of  Managed  Objects  for  Bridges.”  RFC  4188.  May  be  superseded 
or  amended  by  update.  Retrieved  8  May  2017.  Available  at  https://datatracker.ietf.org/doc/rfc4188/. 

^  Internet  Engineering  Task  Force.  “Simple  Network  Management  Protocol  (SNMP)  Applications.”  RFC  3413. 
May  be  superseded  or  amended  by  update.  Retrieved  18  April  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc3413/. 

*  Internet  Engineering  Task  Force.  “Textual  Conventions  for  SMIv2.”  RFC  2579.  April  1999.  May  be  superseded 
or  amended  by  update.  Retrieved  18  April  2017.  Available  at  https ://datatracker. ietf  org/doc/rfc2579/. 
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NOTE 


The  RowStatus  column  is  used  to  manage  the  creation  and  deletion  of  table  rows 
as  well  as  provide  status.  Table  25-1  provides  an  overview  of  the  RowStatus 
values  for  quick  reference.  Refer  to  RFC  2579  for  additional  information. 


Table  25-1.  RowStatus  Values  Overview 

Value 

Description 

Command 

Status 

active 

Row  is  accessible 

notInService 

Row  exists  but  is  not  currently 
accessible 

notReady 

Row  exists  but  is  missing  information 

X 

createAndGo 

Create  a  new  row  and  have  the  row’s 
status  set  to  ‘active’ 

X 

create  AndWait 

Create  a  new  row  and  have  the  row’s 
status  set  to  ‘notReady’ 

X 

destroy 

Delete  a  row 

X 

25.2.2  TmNS-Specific  Management  Resources 

All  management  resources  that  are  TmNS-specific  fall  under  the  top-level  hierarchy 
element  “tmns”.  These  resources  are  categorized  into  the  four  sub-categories  presented  in  Figure 
25-1. 


Figure  25-1.  TmNS-Specific  Management  Resources  Hierarchy 


NOTE 


y 


Only  the  first  level  sub-containers  of  management  resources  are  mentioned  in 
the  sections  below.  As  a  matter  of  consolidating  documentation,  considerably 
more  detail  is  provided  in  the  management  resource  matrix. 


25.2.2.1  tmnsTmaCommon 

The  tmnsTmaCommon  resource  is  a  container  of  management  resources  that  shall  be 
available  on  all  TMAs  unless  otherwise  noted.  It  contains  the  following  six  resource  containers: 

•  tmnsTmaCommonIdentification 

•  tmnsTmaCommonFault 

•  tmnsTmaCommonConfiguration 

•  tmnsTmaCommonControl 
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•  tmnsTmaCommonStatus 

•  tmnsTmaCommonSecurity 

All  TmNS-specific  management  resources  contained  within  this  resource  container  are 
found  in  the  management  resource  matrix. 

25.2.2.2  tmnsT maSpecificC  apabilities 

The  tmnsTmaSpecificCapabilities  resource  is  a  container  of  management  resources  for 
application-specific  capabilities.  Resource  containers  that  reside  under  the 
tmnsTmaSpecificCapabilities  resource  group  management  resources  by  capabilities.  These 
resource  containers  are: 

•  tmnsNetworkFabricDevice 

•  tmnsACU 

•  tmnsDAU 

•  tmnsRecorder 

•  tmnsMasterClock 

•  tmnsSSTTx 

•  tmnsSSTRx 

•  tmnsAdapter 

•  tmnsRCDataSource 

•  tmnsLTCDataSource 

•  tmnsLTCDataSink 

•  tmnsConsolidatedManager 

•  tmnsRadio 

•  tmnsLinkManager 

•  tmnsRCDataSink 

•  tmnsVoiccGateway 

•  tmnsTPA 

•  tmnsPCMGateway 

•  tmnsNetworkGateway 

•  tmnsRAN 

•  tmnsTmnsSourceSelector 

A  TMA  that  supports  a  resource  container  shall  support  all  management  resources  within 
that  resource  container  unless  otherwise  noted. 

All  TmNS-specific  management  resources  contained  within  this  resource  container  are 
found  in  the  management  resource  matrix. 
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25.2.2.3  tmnsNetworkNode 

The  tmnsNetworkNode  resource  is  a  container  of  management  resources  that  provide 
status  and  control  capabilities  that  are  specific  to  the  host  machine.  For  NetworkNodes  that  only 
run  a  single  TMA,  the  TMA  shall  implement  all  management  resources  contained  within  the 
tmnsNetworkNode  resource  container.  If  more  than  one  TMA  are  executed  concurrently  on  a 
single  NetworkNode,  only  one  TMA  is  required  to  implement  the  management  resources 
contained  within  the  tmnsNetworkNode  resource  container.  The  TMAs  that  implement  the 
tmnsNetworkNode  resource  container  shall  support  all  management  resources  within  the 
tmnsNetworkNode  resource  container  unless  otherwise  noted.  The  four  resource  containers 
contained  within  tmnsNetworkNode  are  the  following: 

•  tmnsNetworkNodeldentification 

•  tmnsNetworkNodeConfiguration 

•  tmnsNetworkNodeControl 

•  tmnsNetworkNodeStatus 

All  TmNS-specific  management  resources  contained  within  this  resource  container  are 
found  in  the  management  resource  matrix. 

25.2.2.4  tmnsGeneralNotification 

All  TMAs  shall  be  capable  of  generating  event-based  notifications.  Management 
resources  regarding  general  notifications  are  contained  within  the  tmnsGeneralNotifications 
container  resource.  This  container  resource  contains  the  following  nine  resource  containers: 

•  configurationCompleteNotificationBranch 

•  timeLockLostNotificationBranch 

•  ieee  158  SMaxOffsetFromMasterNotificationBranch 

•  ieee  1 5  8  8Max  J  itterNotificationBranch 

•  tempOutOfRangeNotificationBranch 

•  accessAnomalyDetectionNotificationBranch 

•  powerFaultNotificationBranch 

•  invalidInputNotificationBranch 

•  configurationChangeNotificationBranch 

All  TmNS-specific  management  resources  contained  within  this  resource  container  are 
found  in  the  management  resource  matrix. 

25.3  Management  Resource  Matrix 

The  management  resource  matrix  is  the  table  that  defines  all  TmNS-specific  management 
resources.  Each  row  in  the  matrix  represents  a  management  resource.  Each  column  describes 
the  resource.  The  matrix  can  be  used  to  auto-generate  files  for  various  management  protocols. 

A  software  tool  has  been  provided  that  will  convert  the  management  resource  matrix  into  an 
ASN.l -formatted  TMNS-MIB  file  that  shall  be  used  by  applications  that  use  the  SNMP  protocol. 
Another  software  tool  provided  converts  the  management  resource  matrix  into  a  *.json  file  that 
can  be  used  by  other  available  tools  to  auto-generate  Hypertext  Markup  Eanguage  (HTME) 
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documentation  of  the  management  resources  as  well  as  a  basic  HTTP  clients  and  servers  for  a 
more  RESTful  approach  to  system  management.  Both  tools  are  available  from  the  zip  file 
located  here.  The  TMNS-MIB.mib  file  and  the  TMNS-REST-API.json  file  have  been  generated 
from  the  tools  and  are  readily  available  for  download  from  the  RCC. 

The  columns  of  the  matrix  are  described  in  more  detail  in  the  sub- sections  that  follow. 
25.3.1  Hierarchy  Element  Class 


This  field  indicates  the  class  of  the  management  resource  with  respect  to  its  structure  in 
the  management  resource  hierarchy.  The  possible  values  are  provided  in  Table  25-2. 


Table  25-2.  Hierarchy  Element  Classes 

Value 

Name 

Description 

B 

Branch 

A  branch  in  the  management  resource  hierarchy  that  may  contain 
child  entries. 

I 

Identity 

An  element  that  serves  as  the  management  resource  module 
identifier  for  the  TmNS. 

S 

Scalar 

A  leaf  node  in  the  management  resource  hierarchy. 

N 

Notification 

A  management  resource  that  is  used  for  asynchronous  reporting  of 
management  resources  based  on  some  triggering  condition. 

T 

Table 

A  hierarchical  structure  of  management  resources  that  may  be 
duplicated  across  several  instances.  Management  resources  that 
comprise  a  table  are  the  table  sub-elements,  each  of  which 
comprise  a  column  of  the  table.  Rows  of  a  table  correspond  to 
each  distinct  instance  of  the  collection  of  table  sub-element 
management  resources.  Rows  are  unique  based  on  a  unique 
combination  of  the  table’s  defined  index  values.  A  table  may 
contain  more  than  one  index  value  in  order  to  guarantee  row 
uniqueness. 

ts 

Table  Sub-element 

An  element  of  scalar  type  that  comprises  a  column  of  the  parent 
table. 

TC 

Textual 

Convention 

A  syntax  definition  that  associates  specific  constraints  with  its  type. 
Often  these  constraints  resolve  to  an  integer  enumeration.  The 
textual  convention  may  be  used  as  a  valid  resource  syntax  for  other 
management  resources. 

25.3.2  Resource  Name 

This  field  contains  the  name  of  the  management  resource,  which  shall  be  unique  across 
all  TmNS-specific  management  resources. 

The  resource  name  shall  map  to  the  name  of  the  MIB  variable  within  the  TMNS-MIB. 
Similarly,  management  resource  names  of  the  public  REC  MIBs  are  already  known. 

The  HTTP-based  names  beginning  with  “tmns”  shall  be  considered  as  a  short-cut  to  the 
longer  equivalent  name  enforced  by  the  TMNS-MIB.  That  is, 
iso:org:dod:internet:private:enterprises:tmns. 
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NOTE 


Resource  names  in  the  management  resource  matrix  have  been  chosen  such 
that  they  are  compatible  with  both  known  targets:  SNMP  and  HTTP.  The 
SNMP  MIBs  require  uniqueness  for  all  names  within  a  MIB.  The  intention  is 
for  the  management  resource  names  to  match  that  of  the  MIB  variable  names. 


25.3.3  Parent  Resource  Name 

This  field  shall  contain  the  name  of  its  parent  resource  within  the  management  resource 
hierarchy. 

25.3.4  Resource  Position 

This  field  represents  the  resource’s  child  position  with  respect  to  its  parent  resource.  The 
value  of  this  field  shall  be  an  integer  greater  than  zero  and  is  not  required  to  be  sequential.  The 
resource  position  shall  be  unique  amongst  all  resources  that  share  a  common  parent  resource. 

25.3.5  Resource  URN 

This  field  contains  the  URN  associated  with  the  resource.  The  syntax  for  TmNS-specific 
management  resources  is  defined  in  Section  25.5. 

25.3.6  MIB  Object  Identifier  (OID) 

This  field  represents  the  numerical  hierarchy  associated  with  the  resource,  beginning  with 
the  numerical  value  associated  with  the  root  of  the  TmNS-specific  management  resource  tree, 
“tmns”,  which  has  a  value  of  31409.  For  the  complete  MIB  OID,  see  Subsection  25.4.1. 


25.3.7  Resource  Syntax 

This  field  represents  the  syntax  associated  with  the  resource.  Resources  may  utilize  a 
syntax  with  constraints  as  well  as  syntax  types  that  are  defined  by  textual  conventions  within  a 
supported  public  RFC  or  within  the  TmNS.  Examples  of  syntax  constraints  may  be  in  size 
limitation,  range  of  acceptable  values,  and  enumerations. 


Resources  that  are  textual  conventions  defined  by  the  TmNS  are  not  accessible  resources 
for  reading  or  writing.  As  such,  these  resources  do  not  exist  in  the  hierarchy  of  managed 
resources,  e.g.,  they  have  neither  a  parent  resource  association  nor  a  resource  position. 


NOTE 


Resource  syntax  in  the  management  resource  matrix  has  been 
chosen  such  that  they  reflect  the  syntax  type  constraints 
associated  with  the  MIB  definition  of  the  resources. 


25.3.8  Access  Level 

This  field  contains  the  type  of  access  associated  with  the  resource.  The  possible  access 
levels  and  their  descriptions  are  provided  in  Table  25-3. 


Table  25-3.  Management  Resource  Access  Levels 

Value 

Description 

read-only 

The  resource  only  supports  reading  and  cannot  be  written. 

read-write 

The  resource  supports  both  reading  and  writing. 
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read-create 

The  resource  supports  both  reading  and  writing  and  resides 
within  a  table  that  allows  the  creation  of  new  rows  (instances) 
through  management  via  application  layer  protocols. 

not- 

accessible 

The  resource  does  not  support  reading  or  writing.  These 
resources  are  typically  associated  with  tables  and  do  have  an 
associated  syntax  for  the  purpose  of  hierarchy  structure. 

<blank> 

Resources  that  define  textual  conventions  or  only  provide 
structure,  such  as  parent  resources,  shall  be  left  blank. 

25.3.9  Default  Value 

Default  values  are  given  for  all  readable  resources  unless  otherwise  indicated.  For 
instance,  the  default  value  for  a  table  is  an  “empty”  state  because  it  has  no  rows. 

In  the  case  of  read-only  resources  that  report  status,  the  defaults  shall  be  applied  during 
TMA  initialization;  the  actual  status  value  shall  replace  the  default  value  once  the  TMA  is  able  to 
acquire  that  status. 

In  the  case  of  configuration  and  readable  control  resources,  the  default  values  listed  shall 
be  applied  to  the  TMA  when  a  TMA  “Reset  to  Default”  is  executed. 

25.3.10  Table  Index  # 

This  field  shall  be  used  by  any  table  sub-element  that  serves  as  an  index  into  the  table. 
The  value  shall  be  an  integer  that  indicates  its  index  position  in  relation  to  any  other  indexes 
associated  with  the  table. 

For  any  resource  that  does  not  serve  as  an  index  into  a  table,  this  value  shall  be  left  blank. 

25.3.11  Date  Introduced 

This  field  identifies  the  version  of  the  standard  in  which  the  particular  management 
resource  was  introduced  into  the  standard.  This  is  intended  to  aid  in  interoperability  as  the 
standard  is  updated  and  new  resources  are  added  or  existing  resources  are  updated. 

25.3.12  Persistent 

If  the  Persistent  property  is  true,  the  resource’s  value  shall  be  retained  across  resets 
(including  host  loss  of  power)  except  when  a  TMA  “Reset  to  Default”  is  executed.  The  TmNS 
management  resources  shall  not  be  persistent  except  where  specifically  designated.  Resources 
designated  as  persistent  shall  have  their  value  stored  in  non-volatile  memory  whenever  the 
resource  is  written.  Persistent  resources  shall  not  retain  their  value  when  a  TMA  “Reset  to 
Default”  is  executed. 

25.3.13  Idempotency 

A  resource  with  the  Idempotency  property  set  to  “true”  indicates  that  a  readable  resource 
can  be  read  multiple  times  without  affecting  the  resource’s  value  and  that  a  writeable  resource 
can  be  written  multiple  times  without  adverse  consequences.  The  Idempotency  property  shall 
apply  to  all  TmAS-specific  management  resources  except  where  specifically  noted. 
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25.3.14  Description 

This  field  describes  the  management  resource.  For  some  resources,  specific  behaviors 
and/or  relationships  to  other  management  resources  are  defined.  This  field  shall  be  used  for 
documentation  of  the  management  resource.  A  description  shall  be  provided  for  each 
management  resource. 

25.3.15  Comment 

This  field  provides  additional  comments  that  may  accompany  a  management  resource  or 
group  of  resources.  Comments  shall  not  include  information  that  is  needed  for  understanding 
how  to  use  a  particular  resource  or  set  of  resources. 

25.4  Management  Protocols 

Two  application  layer  protocols  provide  access  to  the  ManagementResources:  SNMP 
and  HTTP. 

25.4.1  SNMP-based  ManagementResources 

All  TMAs  that  provide  or  access  SNMP-based  management  resources  shall  comply  with 
the  SNMP  requirements  specified  in  Chapter  22.  The  TMNS-MIB  contains  all  TmNS-specific 
management  resources.  At  the  top  of  the  TmNS-specific  management  resource  hierarchy  is  the 
resource  “tmns”. 

The  TMNS-MIB  has  the  following  OID  registered  with  the  Internet  Assigned  Numbers 
Authority  (lANA): 

Telemetry  Network  Standard  ( tmns):  iso.org.dod.internet.private.enterprise.3 1409 
(1.3.6.1.4.1.31409) 

Documentation  for  the  TMNS-MIB  is  part  of  the  management  resource  matrix.  An 
ASN.l  formatted  file  can  be  generated  from  the  management  resource  matrix  and  shall  contain 
the  available  documentation  for  each  resource  identified  by  the  TMNS-MIB.  Figure  25-2  depicts 
the  network  connection  used  to  transport  SNMP  requests  and  SNMP  responses  between  a 
manager  and  an  agent. 


Figure  25-2.  SNMP-Based  Management  Resources  Terminology  Overview 


25.4.2  HTTP-based  ManagementResources 

All  TMAs  that  provide  or  access  HTTP-based  resources  shall  comply  with  the  HTTP 
requirements  specified  in  Chapter  22. 
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As  depicted  in  Figure  25-3,  ResourceChannel  identifies  a  network  connection  used  to 
transport  ResourceRequests  and  ResourceResponses  between  a  ResourceClient  and  a 
ResourceServer.  ResourceClients  and  ResourceServers  using  the  ResourceChannel  shall 
exchange  ResourceRequests  and  ResourceResponses  using  the  HTTP,  as  specified  in  Chapter  22. 


Figure  25-3.  HTTP-Based  Management  Resources  Channel  Overview 


The  ResourceClient  shall  act  as  the  HTTP  client  and  the  ResourceServer  shall  act  as  the 
HTTP  server.  Each  TMA  shall  include  a  ResourceServer. 

ResourceClients  and  ResourceServers  shall  transport  ResourceRequests  and 
ResourceResponses  in  the  ResourceChannel  using  TCP. 

The  ResourceChannel  shall  use  the  same  Differentiated  Service  Code  Points  (DSCPs)  in 
both  directions  based  on  the  DSCP  selected  by  the  ResourceClient. 

The  ResourceChannel  shall  support  the  following  HTTP  methods:  GET,  PUT,  POST, 
and  DEEETE.  Support  for  other  HTTP  methods  is  not  required.  The  HTTP  methods  used  in  the 
ResourceRequest  shall  use  the  TmNS_Request_Defined_URI  to  access  ResourceServer  resources. 


Key  ResourceRequest  HTTP  Request  Headers: 


Request  Header 

Value 

Comments 

Host 

Domain  name  and  TCP  port  of 
ResourceServer. 

Required  for  all  HTTP/ 1.1 
requests 

Accept 

Media  Type(s)  (i.e.,  Content-Types) 
acceptable  in  the  ResourceResponse. 

See  Media  Type  discussion  in 

Table  25-4. 

Table  25-4.  Required  and  Optional  Media  Types 

Required  Media  Types 

Media  Type 

Comments 

Common 

Abbr 

application/vnd .  tmns .  mdl-i-xml 

lANA-registered  Media  Type  for  TmNS 

Metadata  Eanguage 

MDE 

application/vnd .  tmns .  arl-i-xml 

lANA-registered  Media  Type  for  TmNS 
Management  Resources  Eanguage 

Optional  Media  Types 

Media  Type 

Comments 

application/vnd.tmns.ihal-i-xml 

lANA-registered  Media  Type  for  TmNS 
Instrumentation  Hardware  Abstraction  Eanguage 

IHAE 

application/xml 

Generic  XME  document  exchange 
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text/html 

Serve  HTMF  pages  to  a  web  browser 

text/plain 

Web  browser  support  via  Javascript  or  similar 
protocol 

others 

Other  Media  Types  may  be  implemented  at  the 
vendor’s  discretion  (although  other 
representations  are  outside  the  scope  of  these 
standards). 

If  a  ResourceRequest  or  ResourceResponse  includes  an  Entity  Body,  the  following  HTTP 
headers  shall  be  in  the  ResourceRequest  or  ResourceResponse  respectively: 


Response  Header 

Value 

Comments 

Content-Type 

The  Media  Type  of  the 
ResourceResponse  body. 

See  Media  Type  discussion  in 

Table  25-4. 

Content-Fength 

Fength  of  ResourceResponse  body 
in  bytes. 

Focation 

Used  in  redirection 

Primarily  used  for  resource  creation 
and  asynchronous  operations 

NOTE 


Supporting  multiple  Accept  header  values  provides  a  ResourceServer  the 
capability  to  support  multiple  interfaces  for  the  same  resource.  For  example: 
the  GET  {rootPathj/dataChannel  method  could  return  a  media  type  of 
“text/html”  and  thereby  provide  the  Data  Channel  Fist  as  an  HTME  page 
(i.e.,  web  page)  rather  than  as  an  XME  document. 


If  a  ResourceServer  receives  a  ResourceRequest  for  an  unrecognized  or  unsupported 
Resource,  the  ResourceServer  shall  return  a  status  code  of  404,  Not  Found. 


If  a  ResourceServer  receives  a  ResourceRequest  with  an  unrecognized  uniform  resource 
identifier  (URI)  parameter  {TmNSparam),  the  ResourceServer  shall  return  an  error  response  with 
all  pertinent  information  included  in  the  error  message  and  a  status  code  of  400,  Bad  Request. 

If  a  ResourceServer  receives  a  ResourceRequest  and  is  unable  to  process  the  request  due 
to  an  internal  ResourceServer  problem,  the  ResourceServer  shall  return  an  error  response  with  all 
pertinent  information  included  in  the  error  message  and  a  status  code  of  500,  Internal  Server 
Error. 


25.4.3  TmNS  Resource  Management  Protocols 
25.4.3.1  Device  Configuration  Protocol 

All  TMAs  shall  support  the  transfer  of  configuration  files  (e.g..  Metadata  Description 
Fanguage  [MDF]  instance  documents)  using  the  File  Transfer  Protocol  (FTP)  as  specified  in 
Chapter  22. 

All  TMAs  should  support  the  transfer  of  configuration  files  using  the  HTTP  as  specified 
in  Chapter  22. 
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25.4.3.1.1  Configuration  Protocol  for  TMAs 

The  TMA  Configuration  Protocol  is  a  sequence  of  steps  executed  between  a  TmNSApp 
manager  and  a  target  TMA  to  configure  the  target  TMA  using  an  MDL  instance  document. 


The  TMA  Configuration  Protocol  is  comprised  of  the  following  steps. 

1 .  The  TmNSApp  manager  sets  the 

tmnsT  maCommon :  tmnsTmaCommonConfiguration :  configurationURI  resource 
on  the  target  TMA  to  the  location  of  the  configuration  file. 


2.  The  TmNSApp  manager  sets  the 

tmnsTmaCommon:tmnsTmaCommonConfiguration:configure  resource  on  the 
target  TMA  to  “true”.  Once  a  TmNSApp  manager  has  set  the 

tmnsTmaCommon:tmnsTmaCommonConfiguration:configure  resource  to  “true”, 
any  attempt  by  the  TmNSApp  manager  to  change  the  resource’s  value  shall  be  ignored 
until  the  target  TMA  has  set  the  resource’s  value  to  “false”. 


NOTE 


To  cancel  the  configuration  process,  a  TmNSApp  manager  may 
execute  either  a  TMA  reset  or  a  TmNSHost  reset. 


3.  Upon  receipt  of  the 

tmnsTmaCommon:tmnsTmaCommonConfiguration:configure  resource  being  set 
to  true,  the  TMA  shall  retrieve  the  configuration  file  indicated  by  the 
tmnsT maCommon :  tmnsTmaCommonConfiguration : configurationURI  resource . 
If  a  retrieval  error  occurs,  the  TMA  shall  follow  the  steps  outlined  in  Subsection 
25.4.3.1.2. 

4.  Upon  successful  retrieval  of  the  configuration  file,  the  TMA  parses  and  checks  the 
retrieved  configuration  file.  The  TMA  is  not  required  to  perform  an  XML  validation 
of  the  configuration  file  (the  TMA  may  assume  the  configuration  is  valid  with  respect 
to  its  schema).  If  an  anomaly  is  detected,  the  TMA  shall  follow  the  steps  outlined  in 
Subsection  25.4.3.1.2. 

5.  The  TMA  applies  the  changes  found  in  the  configuration  file.  If  an  error  is  detected, 
the  TMA  shall  follow  the  steps  outlined  in  Subsection  25.4.3.1.2. 

6.  When  all  changes  have  been  successfully  applied  to  the  TMA  (i.e.,  configuration  is 
complete),  the  TMA  shall: 

a.  Update  the  TMA’s 

tmnsT  maCommon :  tmnsTmaCommonConfiguration  rconfigurationV  ersion 

resource  according  to  the  format  specified  in  the  description  of  this  resource  in  the 
management  resource  matrix. 

b.  Set  the  TMA ’s  tmnsTmaCommon:tmnsTmaCommonStatus:tmaStateNumber 

resource  to  “2”  and 

tmnsTmaCommon:tmnsTmaCommonStatus:tmaStateString  resource  to 
“Configured”. 
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c.  SettherMA’j' 

tmnsT  maCommon :  tmnsTmaCommonConfiguration :  configChangeCounter 

resource  to  “0”. 


d. 


Set  the  TMA’s 

tmnsTmaCommon:tmnsTmaCommonConfiguration:configure  resource  to 
“false”. 


e.  Send  a  configurationCompleteNotification  via  the 

tmnsGeneralNotification:configurationCompleteNotificationBranch:configur 
ationCompleteNotificationsrconfigurationCompleteNotification  resource.  The 
notification  shall  indicate  a  successful  configuration  attempt. 

f.  Set  the  internal  state  of  the  configuration  “dirty  bit”  value  of  the  TMA  to  “false”. 

The  intent  of  the  configuration  “dirty  bit”  state  is  to  indicate  when  the  configuration  of  a 
TMA  has  changed  through  a  manner  other  than  through  the  configuration  protocol  outlined 
above.  The  value  of  the  <DirtyBit>  element  within  the  MDL  instance  document  that  a  TMA  is 
configured  with  is  ignored  by  the  TMA  during  configuration.  If  no  changes  are  made  to  the 
configuration  of  a  TMA  between  a  successful  configuration  attempt  and  an  export  configuration 
(Subsection  25.4.3.2.1),  the  <DirtyBit>  element  of  the  exported  MDL  instance  document 
produced  by  the  TMA  shall  be  “false”. 

A  resource  that  is  not  set  during  the  configuration  process  shall  retain  its  previous  value 
unless  its  behavior  during  configuration  is  explicitly  stated  to  do  otherwise.  In  the  case  where 
configuration  creates  rows  in  a  table,  default  values  shall  be  used  for  the  new  rows  if  not 
explicitly  set  during  the  configuration  process. 


If  a  configuration  error  occurs,  the  TMA  shall  follow  the  steps  outlined  in  Subsection 
25.4.3.1.2. 


NOTE 


y 


A  TMA  is  only  required  to  store  configuration  information 
applicable  to  itself  (i.e.,  storing  configuration  information  of 
other  TMAs  is  not  required). 


25.4.3.1.2  Configuration  Error  Handling 

If  the  TMA  detects  an  error  during  the  configuration  process,  the  TMA  shall  adhere  to  the 
following  steps. 

1 .  The  TMA  shall  follow  one  of  the  two  following  approaches  in  this  step: 

a.  The  TMA  shall  attempt  to  restore  the  previous  configuration  prior  to  the  initiating 
of  the  configure  attempt.  If  the  TMA  is  able  to  restore  the  previous  configuration, 
the  TMA  shall  set  its 

tmnsT  maCommon :  tmnsTmaCommonConfiguration :  configuration  V  ersion, 
tmnsT maCommon :  tmnsTmaCommonStatus :  tmaStateNumber ,  and 
tmnsTmaCommon:tmnsTmaCommonStatus:tmaStateString  resources  to 
their  previous  values  prior  to  the  initiation  of  the  configuration  process.  If  the 
TMA  was  actively  publishing  or  subscribing  to  TmNSDataMessages  prior  to  the 
initiating  of  the  configuration  attempt,  it  shall  not  return  to  that  mode  of 
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operation.  Rather,  a  TMA  that  recovers  from  a  failed  configuration  attempt  shall 
not  begin  publishing  or  subscribing  to  TmNSDataMessages  until  further 
commanded  to  do  so  by  a  TmNSApp  manager.  The  value  of  the  TMA'?,  internal 
configuration  “dirty  bit”  state  shall  remain  the  same  as  it  was  prior  to  the  failed 
configuration  attempt.  If  the  TMA  is  unable  to  restore  the  previous  configuration 
as  described,  the  TMA  shall  utilize  the  other  error  handling  approach  described 
below  in  lb. 


b.  The  TMA  shall  set  its 

tmnsT  maCommon :  tmnsTmaCommonConfiguration :  configuration  V  ersion 

resource  to  an  empty  string  in  accordance  with  the  description  of  the  resource  in 
the  management  resource  matrix.  The  TMA  shall  set  its 
tninsTmaCommon:tmnsTmaCommonStatus:tmaStateNuniber  resource  to 
“1”  and  its  tmnsTmaCommon:tmnsTmaComnionStatus:tmaStateString 

resource  “Unconfigured”.  The  TMA  shall  not  publish  or  subscribe  to  any 
TmNSDataMessages  until  after  a  successful  configuration  attempt.  The  value  of 
the  TMA’s  internal  configuration  “dirty  bit”  state  shall  be  set  to  “true”. 


NOTE 


y 


A  TMA  is  not  required  to  restore  any  previous  state  after  a 
configuration  failure.  Approach  la  is  expected  to  be  used  by  TMA? 
that  are  capable  of  restoring  the  previous  configuration  state. 


2.  The  TMA  shall  set  the 

tmnsTmaCommon:tmnsTmaCommonFault:activeFaultsTable:faultNumber  and 
tmnsTmaCommon:tmnsTmaCommonFault:activeFaultsTable:faultString 
resources  to  the  appropriate  value  into  a  row  in  the 
tmnsTmaCommon :  tmnsTmaCommonF  ault :  activeF  aultsTable . 

3.  The  TMA  shall  set  its 

tmnsTmaCommonrtmnsTmaCommonConfigurationrconfigure  resource  to 
“false”. 

4.  The  TMA  shall  send  a  configurationCompleteNotification  via  the 

tmnsGeneralNotification:configurationCompleteNotificationBranch:configurati 
onCompleteNotificationsrconfigurationCompleteNotification  resource.  The 
notification  shall  indicate  a  failed  configuration  attempt. 


NOTE^ 

The  following  are  examples  of  possible  configuration  errors. 

a.  The  transfer  of  the  configuration  file  fails. 

r 

b.  An  incomplete  or  invalid  configuration  file  is  received. 

c.  A  value  specified  in  the  configuration  file  conflicts  with  a  TMA  constant 

or  allowable  value  range. 

25.4.3.2  File  Export  Protocols 

All  TMAs  shall  support  the  exporting  of  files  via  the  processes  defined  in  the  following 
sub-section. 


25-14 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  25,  July  2017 


25.4.3.2.1  Export  Configuration  File  Protocol  for  TMAs 

The  Export  Configuration  File  Protocol  for  TMAs  is  a  sequence  of  steps  executed 
between  a  TniNSApp  manager  and  a  target  TMA  to  retrieve  the  target  TMA  ’s  current 
configuration  state  via  an  MDL  instance  document. 

The  Export  Configuration  File  Protocol  is  comprised  of  the  following  steps. 

1.  The  TmNSApp  manager  sets  the 

tmnsTmaCommon:tmnsTmaCommonConfiguration:configurationExportURI 

resource  on  the  target  TMA  to  a  destination  location  for  the  configuration  file. 

2.  The  TmNSApp  manager  sets  the 

tmnsTmaCommon:tmnsTmaCommonConfiguration:exportConfiguration 

resource  on  the  target  TMA  to  “true”.  Once  a  TmNSApp  manager  has  set  the 
tmnsTmaCommon :  tmnsTmaCommonConfiguration :  exportConfiguration 

resource  to  “true”,  any  attempt  by  the  TMA  manager  to  change  the  resource’s  value 
shall  be  ignored  until  the  target  TMA  has  set  the  resource’s  value  to  “false”. 


NOTE^ 

To  cancel  the  export  configuration  file  process,  a  TmNSApp 

manager  may  execute  either  a  TMA  reset  or  a  TmNSHost 

r 

reset. 

3.  Upon  receipt  of  the 

tmnsT  maCommon :  tmnsTmaCommonConfiguration :  exportConfiguration 

resource  being  set  to  “true”,  the  TMA  shall  send  an  MDE  file  that  contains  the 
description  of  the  TMA'?,  current  configuration  to  the  destination  location  indicated  by 
the 

tmnsT  maCommon :  tmnsTmaCommonConfiguration :  configurationExportURI 

resource.  The  <DirtyBit>  element  in  the  exported  MDE  file  shall  contain  the  TMA'? 
current  state  of  its  configuration  “dirty  bit”.  The  “dirty  bit”  state  is  only  set  to  “false” 
after  a  successful  configuration  attempt,  and  it  shall  be  set  to  “true”  when  the 
configuration  state  is  changed  in  a  manner  other  than  through  the  configuration 
protocol  (Subsection  25.4.3.1.1). 


NOTE 


Once  the  configuration  “dirty  bit”  is  set  to  “true”  on  the  TMA,  it 
should  remain  “true”  until  a  successful  reconfiguration  attempt  is 
accomplished  according  to  Subsection  25.4.3.1.1. 


4.  Upon  completion  of  the  file  transfer  process  (successful  or  failed),  the  TMA  shall  set 
the  TMA 

tmnsTmaCommonrtmnsTmaCommonConfigurationrexportConfiguration 

resource  to  “false”. 

5.  If  an  error  occurs,  the  TMA  shall  set  the 

tmnsTmaCommon:tmnsTmaCommonFault:activeFaultsTable:faultNumber  and 
tmnsT  maCommon :  tmnsTmaCommonF  ault :  activeF  aultsT  able :  faultString 
resources  to  the  appropriate  value  into  a  row  in  the 
tmnsT  maCommon :  tmnsTmaCommonF  ault :  activeF  aultsTable . 
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NOTE 


y 


The  full  state  of  the  TMA  is  represented  by  its  stored  eonfiguration  information 
(i.e.,  information  transportable  via  an  MDL  instanee  doeument)  and  the  state  of 
the  TMA' s  resourees.  The  exported  MDL  file  should  eontain  all  updates  of 
management  resourees  that  are  described  in  the  MDL  schema;  however,  some 
resources  are  not  represented  in  the  MDL  schema,  such  as  the  recording  state  of 
a  recorder,  and  are  only  available  through  other  management  resource  access 
methods.  Thus,  it  may  be  necessary  for  a  TmNSApp  manager  to  retrieve  the 
current  values  of  a  TMA' s  resources  in  conjunction  with  retrieving  an  MDL  file 
with  its  current  configuration  state  via  the  export  process. 


A  successfully  exported  MDL  instance  document  from  a  TMA  shall  be  capable  of 
reconfiguring  the  original  TMA  into  the  configuration  state  at  the  time  of  the  export  process.  In 
other  words,  reconfiguring  a  TMA  with  its  exported  MDL  configuration  file  immediately  after  a 
successful  export  configuration  process  completes  shall  result  in  a  successful  configuration  of  the 
TMA. 

25.4.3.2.2  Export  Log  File  Protocol  for  TMAs 


The  Export  Log  File  Protocol  for  TMAs  is  a  sequence  of  steps  executed  between  a 
TmNSApp  manager  and  a  target  TMA  to  retrieve  the  target  TMA'?,  log  file. 


The  Export  Eog  File  Protocol  is  comprised  of  the  following  steps. 


1 .  The  TmNSApp  manager  sets  the 

tmnsTmaCommon:tmnsTmaCommonControl:logFileExportURI  resource  on  the 
target  TMA  to  a  destination  location  for  the  log  file. 

2.  The  TmNSApp  manager  sets  the 

tmnsTmaCommon:tmnsTmaCommonControl:exportLogFile  resource  on  the 
target  TMA  to  “true”.  Once  a  TmNSApp  manager  has  set  the 
tmnsTmaCommonrtmnsTmaCommonControlrexportLogFile  resource  to  “true”, 
any  attempt  by  the  TmNSApp  manager  to  change  the  resource’s  value  shall  be  ignored 
until  the  target  TMA  has  set  the  resource’s  value  to  “false”. 


NOTE^ 

To  cancel  the  Export  Eog  File  Process,  a  TmNSApp  manager 

r 

may  execute  either  a  TMA  reset  or  a  TmNSHost  reset. 

3.  Upon  receipt  of  the  tmnsTmaCommon:tmnsTmaCommonControl:exportLogFile 
resource  being  set  to  “true”,  the  TMA  shall  send  its  log  file  to  the  destination  location 
indicated  by  the  tmnsTmaCommonrtmnsTmaCommonControlrlogFileExportURI 

resource. 

4.  Upon  completion  of  the  file  transfer  process  (successful  or  failed),  the  TMA  shall  set 

the  TMA  tmnsTmaCommon:tmnsTmaCommonControl:exportLogFile  resource 
to  “false”. 

5.  If  an  error  occurs,  the  TMA  shall  set  the 

tmnsT maCommon :  tmnsTmaCommonF ault :  activeF aultsT able :  faultNumber  and 
tmnsT  maCommon :  tmnsTmaCommonF  ault  ractiveF  aultsT  able  :faultString 
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resources  to  the  appropriate  value  into  a  row  in  the 

tmnsT  maCommon :  tmnsTmaCommonF  ault  ractiveF  aultsT  able . 

25.4.3.3  TmNS  Configuration  Negotiation  Protocol 

NetworkNodes  that  sample  and  package  data  and  TmNSAppManagers  that  construct 
MDL  files  shall  implement  the  TmNS  Configuration  Negotiation  Protocol.  The  protocol 
consists  of  a  dialog  between  the  TmNSAppManager  and  the  data  acquisition  NetworkNode.  The 
protocol  is  used  to  communicate  the  desired  set  of  measurements  to  be  produced  and  the 
capability  of  the  acquisition  device  to  provide  the  data  at  the  requested  rates. 


NOTE^ 

In  the  future  this  protocol  may  be  expanded  to 

incorporate  other  NetworkNodes  where  the  scope  of  the 

r 

device  warrants. 

The  communication  between  the  negotiating  entities  utilizes  HTTP  (Chapter  22 
Subsection  22.5.2.2),  SNMP  (Chapter  22  Subsection  22.5.2.1,  this  chapter),  and  FTP  (Chapter  22 
Subsection  22.5.2.4).  The  communication  workflow  is  depicted  in  Figure  25-4. 


TmNSAppManager 


Describe  Measured  Parameters 

-  Create  &  store  measurements 

-  Create  &  store  transducers 


Acquire  DAU  Inventory 
-  Send  inventory  MDL  request 


<n‘mNSDAU: 

Apply  Measured  Parameters 

-  Bind  measurements  to  ports 

-  Create  MDL  <PortMappingS' 


Retrieve  inventory  MDL  from 
HTTP  message  <body> 


<Po'tMapp"^E> 


<Netwcrt(Mode> 

<TmNSOAU» 

<Module> 

«VendoiConfl9> 

<Dev>ce> 

<PonMappan9»> 


Validate  DAU  MDL 
.  •  Send  configuration  MDL  in 


HTTP  message  <body> 


Launch  validation  editor  (if  impieinented  on  OAU) 


Retrieve  Validated  MDL 
•  Get  validated  MDL  configuration 


Validation  Editor 
-  Launch  validation  editor 


Vendor  Specific 
MDL  Editor 


•  Retrieve  configuration  MOL 
from  HTTP  message  <body> 


Configure  OAU 


Export  DAU  Configuration 


Note: 

The  protocol  keys  on  2  mandatory  resources: 

http:///iosfname/tmns/v1/inventory 

http:///io5f/ia/ne/tmns/v1/validalion/candidate 

The  protocol  may  utilize  2  optional  resources; 

http;///)ostname/tmns/v1/val<dation/editor/interface 

http:///iostname/tmns/v1/valldation/edilor/MDL 

The  URIs  below  are  abbreviated  for  brevity. 


DAU  NetworkNode 
(actual  or  emulated) 


- HTTP  GET  inventory — 

HTTP  200  OK 

<bodyxMOLRoot>,  </MDLRoolxrt>oc»y> 
- 4xx  ERROR - 


Where  appropriate,  headers  should  include: 
Content-Type;  Application/vnd.tmns.mdI+xml; 
charsel="utf-8’' 


Export  DAU  Inventory 
-  Create  inventory  MDL.  Includes 
default  values  for  any/all 
<GenericParameters> 


_ HTTP  PUT  validation/candidate _ 

<tiody»<MDLRoot»  ..</MOLRool><fbody» 

HTTP  204  NO  CONTENT - 

HTTP  200  OK  I - 

<l)0(ly>Modinc8ton  Reporl<(body>  I 

HTTP  400  BAD  REQUEST  I - 

<tiody>F«llur«  R«port</body»  ■)  report 


HTTP  GET  validation/candidate - 

HTTP  200  OK  _ 

<bocty»<MDLRoot»  .<)MDLRoot»</body> 

—HTTP  GET  validation/editor/interface 
- HTTP  200  OK - 


HTTP,  VerxJor  Specific 


— HTTP  GET  validation/editor/MDL— 
HTTP  200  OK 

<boOy><M[X.Root>.  </MOLRoot><rbody» 


-  On  success,  send  200  OK 
with  inventory  MDL  in  the 
HTTP  message  <body> 

•  On  error,  send  4xx  or  5xx  status 

Validate  Candidate  Config  MOL 

-  Retrieve  candidate  configuration  MDL  from 
HTTP  message  <body>  and  validate  MDL  for 
vendor  specifics 


MOL 
<NetworkN< 


</Module> 

<TmNSDAU> 


-  Candidate  MDL  is  valid  with  no  modifications, 
send  204  NO  CONTENT 

-  Candidate  MDL  is  valid  but  was  modified,  send 
200  OK  with  modification  report  in  the  message 
<body> 

-  Candidate  MDL  is  invalid,  send  400  BAD 
REQUEST  with  failure  report  in  the  message 
<body> 

Export  Validated  MOL 

-  send  200  OK  with  valid  configuration 
MDL  in  HTTP  message  <body> 


Validation  Editor 


Vendor  Specific  MDL  Editor 

-  Vandor  SpraKc  Ul 

-  MDL  aiMor  proviMs  Ui  to  te»or>e  l-jr  v«lidsto(i 

•  Edits  arm  vaMatsd  pnor  to  commlBing  mcxMtoations 

-  Stora  valid  oonAgunMian  MDL  in  validalioivadftor.'MOL 


-  send  200  OK  with  valid  configuration 
MDL  in  HTTP  message  <body> 


MDL 

<Measuremeo(s> 

►  <Networi(> 

<NelwofkNode> 

<TmNSDAU> 

<Device> 

<PortMappings> 


SET  cortflguralionURl.  conhgura 
- FTP  GET - 


;^DAU  NetworkNode  (actual)  J 

Configure  DAU 


SET  cortflguratlonExponURI.  enportConflguration 


f  Export  DAU  Configuration 


MDL 


<M(mijn»wrii$>  I 


<TmNSCiAU> 

<Meduia> 

<VendDfCflnnQ> 


Figure  25-4.  TmNS  Configuration  Negotiation  Protocol  Diagram 
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The  TmNS  Configuration  Negotiation  Protocol  is  a  sequence  of  steps  executed  between  a 
TmNSAppManager  and  a  data  acquisition  NetworkNode  to  a  build  a  valid  MDL  instance 
document  containing  the  data  acquisition  NetworkNode  configuration. 

The  TmNS  Configuration  Negotiation  Protocol  is  comprised  of  the  following  steps. 

1.  The  TmNSAppManager  retrieves  inventory  from  the  data  acquisition  NetworkNode 
by  accessing  the  Inventory  Resource  on  data  acquisition  NetworkNode. 

2.  The  TmNSAppManager  binds  measurement  information  to  the  data  acquisition 
NetworkNode  inventory,  creating  a  candidate  for  the  data  acquisition  NetworkNode 
configuration. 

3.  The  TmNSAppManager  sends  the  candidate  MDL  instance  document  to  the 
Validation  Candidate  Resource  on  the  data  acquisition  NetworkNode.  This  initiates 
the  validation  process  on  the  NetworkNode,  but  it  does  not  actually  configure  the  data 
acquisition  NetworkNode.  The  standard  HTTP  response  provides  the  result  of  the 
validation  operation. 

a.  If  data  acquisition  NetworkNode  considers  the  candidate  MDL  instance  valid,  the 
NetworkNode  will  update  the  Validation  Candidate  Resource  with  the  candidate 
MDL  instance  document.  The  response  will  indicate  success  to  the 
TmNSAppManager. 

b.  If  the  data  acquisition  NetworkNode  considers  the  candidate  MDL  instance 
document  valid  only  after  the  NetworkNode  modified  the  content  of  the  candidate 
MDL  instance  document  during  the  validation  process,  the  NetworkNode  will 
update  the  Validation  Candidate  Resource  with  the  candidate  MDL  instance 
document  and  all  associated  annotations  provided  by  the  NetworkNode  during  the 
validation  process.  The  response  will  indicate  success  to  the  TmNSAppManager 
and  shall  contain  a  modification  report  of  the  modifications.  The  content  of  the 
modification  report  is  outside  the  scope  of  this  standard. 

c.  If  the  data  acquisition  NetworkNode  does  not  consider  the  candidate  MDL 
instance  document  valid,  the  NetworkNode  shall  return  an  error  with  a  detailed 
failure  report  in  the  response.  The  NetworkNode  shall  still  update  the  Validation 
Candidate  Resource  even  though  it  is  deemed  an  invalid  configuration  for  the 
device.  The  content  of  the  failure  report  is  outside  the  scope  of  this  standard. 
From  this  point,  a  user  may  repeat  Step  3  by  sending  a  new  candidate  MDL 
instance  document  to  the  NetworkNode,  or  access  the  optional  Validation  Editor 
Interface  Resource  if  one  is  available  on  the  NetworkNode. 

d.  If  the  candidate  MDL  instance  document  is  not  MDL-schema  valid,  the 
NetworkNode  shall  return  an  unsupported  media  type  error. 

4.  Once  the  data  acquisition  NetworkNode  validates  the  candidate  MDL  instance 
document,  the  TmNSAppManager  retrieves  the  valid  configuration  from  the 
Validation  Candidate  Resource  (or  the  Validation  Editor  MDE  Resource,  if 
applicable)  on  the  data  acquisition  NetworkNode. 

5.  The  TmNSAppManager  may  configure  the  data  acquisition  NetworkNode  with  the 
valid  configuration  via  the  TMA  Configuration  Protocol  (see  Subsection  25.4.3.1.1). 
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25.4.3.3. 1  TniNS  Inventory  Resource 

Data  acquisition  NetworkNodes  shall  document  their  inventory  in  an  MDL  instance 
document  by  implementing  the  Inventory  Resource  at  the  URI,  /tmns/v  1 /inventory .  The 
inventory  of  the  NetworkNode  shall  consist  of  the  hardware  modules  that  comprise  the 
NetworkNode  and  may  also  contain  the  capabilities  of  the  associated  hardware  modules.  The 
Inventory  Resource  shall  support  the  HTTP  GET  method.  The  Inventory  Resource  shall  indicate 
success  by  returning  a  200  OK  response  containing  the  inventory  MDL  instance  document  in  the 
body.  The  MDL  instance  document  shall  include  default  values  for  any  and  all 
GenericParameters  required  by  the  device.  The  data  acquisition  NetworkNode  may  indicate 
errors  by  returning  an  appropriate  4xx  or  5xx  status  code  response. 

25.4.3.3.2  TmNS  Validation  Candidate  Resource 

Data  acquisition  NetworkNodes  shall  augment  the  TmNS  Configuration  Protocol  (see 
Subsection  25.4. 3. 1. 1)  by  implementing  the  Validation  Candidate  Resource  at  the  URI 
/tmns/v  1 /validation/candidate.  The  Validation  Candidate  Resource  shall  support  the  HTTP  PUT 
and  GET  methods. 

This  resource  shall  validate  the  candidate  MDL  instance  document  when  accessed  by  a 
PUT  method.  The  body  of  the  PUT  request  shall  contain  the  candidate  MDL  instance  document 
to  be  validated  by  the  NetworkNode.  The  PUT  request  for  the  Validation  Candidate  Resource 
shall  return  one  of  the  following  response  codes. 

•  204  NO  CONTENT:  This  response  shall  be  used  to  indicate  that  the  candidate  MDL 
instance  document  represented  a  valid  configuration  without  any  modification.  The 
body  of  the  response  shall  be  empty.  Validation  is  successful,  and  the  Validation 
Candidate  Resource  shall  be  updated  to  contain  the  candidate  MDL  instance 
document. 

•  200  OK:  This  response  shall  be  used  to  indicate  that  the  candidate  MDL  instance 
document  was  modified  in  order  to  represent  a  valid  configuration.  The  body  of  the 
response  shall  contain  a  modification  report.  Validation  is  successful,  and  the 
Validation  Candidate  Resource  shall  be  updated  to  contain  the  modified 
representation  of  the  candidate  MDL  instance  document. 

•  400  BAD  REQUEST:  The  Validation  Candidate  Resource  represents  a  validation 
failure,  and  the  body  of  the  response  shall  contain  a  detailed  failure  report  of  the 
reason(s)  for  the  failure.  The  Validation  Candidate  Resource  shall  be  updated,  but  the 
value  represents  an  invalid  configuration  for  the  NetworkNode. 

•  415  UNSUPPORTED  MEDIA  TYPE:  This  response  shall  be  used  to  indicate  that  the 
candidate  MDL  instance  document  sent  in  the  PUT  request  does  not  comply  with  the 
MDL  schema  defined  in  Chapter  23. 


A  GET  request  for  the  Validation  Candidate  Resource  shall  return  one  of  the  following 
response  codes. 

•  200  OK:  The  Validation  Candidate  Resource  represents  a  valid  configuration  for  the 

NetworkNode,  and  the  body  of  the  response  message  contains  the  valid  MDL  instance 
document. 
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•  400  BAD  REQUEST:  The  Validation  Candidate  Resource  represents  a  validation 
failure,  and  the  body  of  the  response  contains  the  invalid  MDL  instance  document. 

•  428  PRECONDITION  REQUIRED:  The  Validation  Candidate  Resource  is  not 
available,  and  the  body  of  the  response  is  empty. 

25.4.3.3.3  TmNS  Validation  Editor  Interface  Resource 

The  Validation  Editor  Interface  Resource  is  an  optional  resource  that  may  be 
implemented  by  a  data  acquisition  NetworkNode.  If  implemented,  the  Validation  Editor 
Interface  Resource  shall  support  the  HTTP  GET  method.  If  not  implemented,  the  GET  request 
shall  return  a  404  NOT  EOUND  response. 

A  GET  request  for  the  Validation  Editor  Interface  Resource  shall  launch  an  editor  that 
allows  the  user  to  modify  MDE  content  and  manipulate  vendor- specific  settings.  When  the 
editor  is  launched,  a  200  OK  response  message  is  returned.  The  editor  opens  the  Validation 
Candidate  Resource,  whether  valid  or  not,  but  it  does  not  update  that  resource.  The  user  interacts 
with  the  data  acquisition  NetworkNode  through  the  editor  interface.  Upon  saving  any  choices 
made  by  a  user  within  the  editor,  the  editor  shall  validate  the  resulting  MDE  instance  document. 
If  the  resulting  MDE  instance  document  is  valid  for  the  NetworkNode,  the  MDE  instance 
document  shall  be  saved  to  the  Validation  Editor  MDE  Resource. 

25.4.3.3.4  TmNS  Validation  Editor  MDL  Resource 

The  Validation  Editor  MDE  Resource  shall  be  implemented  by  a  data  acquisition 
NetworkNode  if  the  Validation  Editor  Interface  Resource  is  implemented.  The  Validation  Editor 
MDE  Resource  shall  support  the  HTTP  GET  method. 

A  GET  request  for  the  Validation  Editor  MDE  Resource  shall  return  one  of  the  following 
response  codes. 

•  200  OK:  The  Validation  Editor  MDE  Resource  represents  a  valid  MDE  instance 
document  for  the  NetworkNode,  and  it  is  sent  in  the  body  of  the  response 
message.  The  valid  MDE  instance  document  is  a  result  of  invoking  the  TmNS 
Validation  Editor  Interface  Resource  and  resolving  all  conflicts  within  the  editor. 

•  428  PRECONDITION  REQUIRED:  The  Validation  Editor  MDE  Resource  is 
blank,  and  the  body  of  the  response  is  empty.  This  results  from  a  user  not  saving 
off  a  valid  MDE  instance  document  through  the  editor  provided  through  the 
Validation  Editor  Interface  Resource. 

•  404  NOT  EOUND:  The  Validation  Editor  MDE  Resource  is  not  implemented. 


25.5  Uniform  Resource  Name 

The  TmNS  management  resources  hierarchy  uses  the  URN  defined  in  REG  2141.^  The 
general  syntax  is  specified  below: 

URN  =  "urn:"  Namespace  ID  Namespace  Specific  String  (NSS) 


®  Internet  Engineering  Task  Force.  “URN  Syntax.”  RFC  2141.  Obsoleted  by  RFC  8141.  May  1997.  Retrieved  8 
May  2017.  Available  at  https ://datatracker.ietf. org/doc/rfc2 141/. 
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For  TmNS-specific  management  resources,  the  TniNSURN,  “tmns”  is  assigned  as  the 
Namespace  ID  resulting  in: 

TmNSURN  =  "urn: tmns:"  Namespace  Specific  String  (NSS) 

The  Namespace  Specific  String  (NSS)  identifies  a  specific  resource  or  set  of  resources 
under  the  TmNS  Namespace.  Examples: 

•  urn:tmns:tmnsTmaCommon:tmnsTmaCommonIdentification  identifies  all  of  the 
resources  under  the  tmnsTmaCommonIdentification  resource. 

•  urn:tmns:tmnsTmaCommon:tmnsTmaCommonIdentification:tmaProductName 

specifically  identifies  the  tmaProductName  resource. 


To  reduce  documentation  clutter,  the  “um:tmns”  is  typically  left  off  a  resource’s  name. 
For  example:  the  tmaProductName  resource  would  be  identified  as  the 

tmnsT maCommon : tmnsTmaCommonIdentification : tmaProductName  resource . 
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Acronyms 


DSCP 

Differentiated  Services  Code  Point 

IP 

Internet  Protocol 
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Latency/Throughput  Critical 
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Metadata  Description  Language 

PTP 

Precision  Time  Protocol 

RFC 

Request  for  Comment 

RTSP 

Real  Time  Streaming  Protocol 
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Society  of  Motion  Picture  and  Television  Engineers 

TCP 

Transmission  Control  Protocol 

TmNS 

Telemetry  Network  Standard 

UDP 

User  Datagram  Protocol 

URI 

uniform  resource  indicator 
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CHAPTER  26 

TmNSDataMessage  Transfer  Protocol 


26.1  General 

This  chapter  defines  how  Telemetry  Network  Standard  (TmNS)-specific  data 
(TmNSDataMessages)  are  transferred  between  applications.  A  DataSource  shall  transmit 
TmNSDataMessages  and  a  DataSink  shall  receive  TmNSDataMessages.  A  DataChannel 
identifies  a  logical  network  connection  used  to  transfer  TmNSDataMessages  between  a 
DataSource  and  DataSink. 

A  unicast  DataChannel  is  a  logical  network  connection  between  a  single  DataSource  and 
a  single  DataSink,  as  shown  in  Figure  26-1. 


DataSource 

DataChannel 

DataSink 

/  * 

TmNSDataMessages 

Figure  26- 1 .  Unicast  DataChannel 


A  multicast  or  broadcast  DataChannel  is  a  logical  network  connection  between  a  single 
DataSource  and  one  or  more  DataSinks,  as  shown  in  Figure  26-2. 


Figure  26-2.  Multicast  or  Broadcast  DataChannel 


This  document  describes  how  DataChannels  are  allocated  and  managed  via  application 
data  transfer  resources.  Chapter  25  defines  the  associated  management  resources.  Chapter  21 
Appendix  21-B  describes  the  bit  numbering,  bit  ordering,  and  byte  ordering  conventions  used  in 
this  chapter. 

A  DataChannel  may  be  established  by  submitting  a  ResourceRequest  to  specific 
application  data  transfer  resources  or  via  metadata  (i.e.,  described  in  a  Metadata  Description 
Language  [MDL]  instance  document). 
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Figure  26-3.  Request-Defined  Data  Channel 


26.2  Data  Channel  Characteristics 

The  following  information  describes  a  DataChannel: 

•  Network  Transport  Characteristics 

•  Message  List 

•  Time  Range 

26.2.1  Network  Transport  Characteristics 

TmNSDataMessages  shall  be  transported  using  either  the  User  Data  Protocol  (UDP)  or 
the  Transmission  Control  Protocol  (TCP).  A  DataChannel  shall  support  a  single  Differentiated 
Services  Code  Point  (DSCP)  assignment  as  specified  in  the  Quality  of  Service  section  of  Chapter 
22. 

For  a  metadata-defined  DataChannel,  the  network  transport  characteristics  are  specified 
in  an  MDL  instance  document.  See  Section  26.3  for  more  information. 

For  a  request-defined  DataChannel,  the  network  transport  characteristics  are  included  in 
the  ResourceRequest.  See  Section  26.4  for  more  information. 

26.2. 1 . 1  UDP  DataChannel 

All  UDP-capable  DataSources: 

•  shall  support  sending  TmNSDataMessages  via  UDP/Internet  Protocol  (IP)  multicast, 
as  specified  in  Chapter  22; 

•  should  support  sending  TmNSDataMessages  via  UDP/IP  unicast  or  broadcast,  as 
specified  in  Chapter  22; 

•  shall  send  one  complete  TmNSDataMessage  or  TmNSDataMessage  fragment  per 
UDP  datagram. 


NOTE^ 

It  is  anticipated  that  a  future  version  of  this  chapter  may  allow 

for  multiple  TmNSDataMessages  to  be  delivered  in  a  single 

r 

UDP  datagram. 

All  UDP-capable  DataSinks: 

•  shall  support  receiving  TmNSDataMessages  via  UDP/IP  multicast,  as  specified  in 
Chapter  22; 
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•  should  support  receiving  TmNSDataMessages  via  UDP/IP  unicast  or  broadcast,  as 
specified  in  Chapter  22. 

26.2. 1 .2  TCP  DataChannel 

All  TCP-capable  DataSources  shall  support  sending  TmNSDataMessages  via  TCP/IP,  as 
specified  in  Chapter  22. 

All  TCP-capable  DataSinks  shall  support  receiving  TmNSDataMessages  via  TCP/IP,  as 
specified  in  Chapter  22. 

26.2.2  Message  List 

A  TmNSDataMessage  List  nominally  contains  a  list  of  MessageDefinitionIDs  and 
identifies  which  TmNSDataMessages  shall  be  transported  across  the  DataChannel. 

For  a  request-defined  DataChannel,  the  TmNSDataMessage  list  is  included  in  the 
ResourceRequest. 

For  a  metadata-defined  DataChannel,  the  TmNSDataMessage  list  is  defined  in  an  MDL 
instance  document.  See  Section  26.3  for  more  information. 


26.2.3  Time  Range 

A  time  range  is  comprised  of  a  start  time  and  end  time  where  each  time  specifies  one  of 
the  following: 

•  Past  time:  associated  with  retrieving  data  with  timestamps  before  the  current  time; 

•  Present  time:  associated  with  current  acquisition  (e.g.,  live)  data; 

•  Future  time:  associated  with  future  acquisition  data. 

For  a  request-defined  DataChannel,  the  time  range  shall  be  included  in  the 
ResourceRequest.  Time  ranges  with  various  combinations  of  past,  present,  and  future  time  are 
supported  provided  the  end  time  is  greater  than  the  start  time. 

26.3  Me/arfa/a-Defined  Application  Data  Transfer 

Metadata-defined  Application  Data  Transfer  refers  to  the  TmAS-specific  application-level 
method  of  delivering  TmNSDataMessages  using  an  MDL  instance  document  to  specify 
DataChannel  characteristics. 

Metadata-defined  DataChannels  are  opened  at  TmNSApp  startup/reconfiguration  and 
remain  open  indefinitely. 

26.3.1  Latency/Throughput  Critical  (LTC)  Delivery  Protocol 

The  LTC  Delivery  Protocol  is  the  TmAS-specific  application-level  method  of  delivering 
TmNSDataMessages  via  UDP. 

26.3.2  LTC  Delivery  Protocol  Data  Channel  (LTCDataChannel) 

LTCDataSources  and  LTCDataSinks  shall  support  UDP  Data  Channels  as  defined  in 
Subsection  26.2.1.1 

LTCDataSources  shall  transport  TmNSDataMessages  using  the  UDP  destination  address 
and  port  determined  by  the  following  descending  order  of  precedence. 
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1.  The  address  and  port  associated  with  the  MDID  of  the  delivered  TmNSDataMessage  in 

the  MDL  instance  document.  If  only  the  address  is  available,  the  default  port  is  port 

55555. 

2.  The  broadcast  IP  address  and  port  55555. 

LTCDataSources  and  LTCDataSinks  shall  comply  with  the  standard  TmNSDataMessage 
structure  and  mechanisms  as  specified  in  Chapter  24. 

26.4  Request-Defined  Application  Data  Transfer 

Request-defined  Application  Data  Transfer  refers  to  the  TmNS-specific  application-level 
method  of  delivering  TmNSDataMessages  via  a.  ResourceClient’s  data  request  {DataRequest). 

26.4.1  Real  Time  Streaming  Protocol  (RTSP)-based  Control  Channel  (RTSPContwlChannel) 

DataSources  and  DataSinks  (referred  to  as  RTSPDataSources  and  RTSPDataSinks 
respectively)  using  the  RTSPControlChannel  shall  exchange  control  commands  and  parameters 
using  RTSP,  as  specified  in  Request  for  Comment  (RFC)  2326.^ 

RTSPDataSources  and  RTSPDataSinks  shall  transport  RTSP  commands  in  the 
RTSPControlChannel  using  TCP. 

The  RTSPDataSink  shall  act  as  the  RTSP  client  and  the  RTSPDataSource  shall  act  as  the 
RTSP  server. 

The  RTSP  server  shall  listen  for  a  TCP  connection  on  the  TCP  port  specified  in  the 
ListeningPort  element  under  the  TmNSRCDataSource  element  in  the  MDL  instance 
document.  If  no  port  is  specified,  then  port  55554  shall  be  used. 

The  RTSP  client  shall  establish  an  RTSPControlChannel  using  the  TCP  port  specified  in 
the  ListeningPort  element  under  the  selected  TmNSRCDataSource  element  in  the  MDL 
instance  document.  If  no  port  is  specified,  then  port  55554  shall  be  used. 

The  RTSPControlChannel  shall  use  the  same  DSCP  in  both  directions  based  on  the 
DSCP  selected  at  origination  of  the  RTSPControlChannel  by  the  RTSPDataSink. 

When  an  RTSPDataSource  cannot  perform  in  the  manner  specified  in  this  standard,  the 
RTSPDataSource  shall  issue  the  appropriate  error  Status-Code  specified  in  RFC  2326. 

An  RTSPDataSource  shall  return  all  TmNSDataMessages  that  match  a  particular 
TmNS_Request_Defined_URI  request  and  shall  include  an  End  of  Data  Indication  (see 
Subsection  26.4.2.2). 


The  RTSPControlChannel  shall  support  the  following  RTSP  commands:  “OPTIONS” 
“SETUP,”  “TEARDOWN,”  “PEAY,”  and  “PAUSE”  methods.  Table  26-1  identifies  the 
required  RTSP  headers  for  the  mandatory  RTSP  methods. 


Table  26-1. 

Required  RTSP  Header 

Header 

Type 

Methods 

Comment 

Bandwidth 

Request 

PEAY 

See  Subsection  26.4.1.3  for  details. 

'  Internet  Engineering  Task  Force.  “Real  Time  Streaming  Protocol  (RTSP).”  RFC  2326.  Obsoleted  by  RFC  7826. 
April  1998.  Retrieved  8  May  2017.  Available  at  https://datatracker.ietf.org/doc/rfc2326/. 
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Connection 

Request 

Response 

ALL 

Only  applieable  eonnection  token  is  “elose”. 

CSeq 

Request 

Response 

ALL 

Public 

Response 

OPTIONS 

Only  used  in  response  to  an  OPTION  request. 

Range 

Request 

Response 

PLAY 

See  Subseetion  26.4.1.2  for  details. 

Session 

Request 

Response 

PLAY, 

PAUSE, 

TEARDOWN 

Speed 

Request 

PEAY 

See  Subseetion  26.4.1.3  for  details. 

Transport 

Request 

Response 

SETUP 

See  Subseetion  26.4.1.1  for  details. 

All  RTSP  clients  and  servers  may  support  additional  RTSP  eommands  and  assoeiated 
header  fields  as  specified  in  Request  for  Comment  (RFC)  2326. 


26.4. 1 . 1  Transport  Header 

The  RTSP  transport  header  shall  be  supported  by  RTSPDataSources  and  RTSPDataSinks 
using  the  RTSPControlChannel.  The  transport  header  indieates  whieh  transport  protoeol  is  to  be 
used  and  configures  its  parameters,  such  as  destination  address,  multicast  time-to-live,  and 
destination  port.  A  transport  request  header  field  may  contain  a  list  of  transport  options 
acceptable  to  the  elient.  Transport  options  are  eomma-separated,  listed  in  order  of  preferenee. 
Parameters  may  be  added  to  eaeh  transport  option,  separated  by  a  semieolon.  All 
RTSPDataSources  and  RTSPDataSinks  shall  support  the  following  transport  header  parameters. 


Transport  = 

transport-spec  = 

transport-protocol  = 
profile  = 

lower-transport  = 

parameter  = 


ttl 

port 

address 


"Transport" 

l\#transport-spec 

transport-protocol /profile [ /lower-transport ] 
*parameter 
" TMNS " 

" TMNSP" 

"TCP"  I  "UDP" 

(  "unicast"  |  "multicast"  ) 

"destination"  [  "="  address  ] 

"ttl"  "="  ttl 

" client_port "  "="  port  [  port  ] 

1*3 (DIGIT) 

1*5 (DIGIT) 
host 


NOTE 


This  standard  deviates  from  RFC  2326  (whieh  states  that  a  lower- 
transport  protocol  of  “TCP”  results  in  interleaving  user-request  data 
onto  the  RTSPControlChannel)  by  interpreting  the  lower-transport 
protoeol  of  “TCP”  as  requiring  a  separate  TCP  data  ehannel  (not  an 
interleaved  eontrol-i-data  channel).  See  Subsection  26.4.2. 
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26.4.1.2  Range  Header 

The  following  Precision  Time  Protocol  (PTP)  Time  Range  format  shall  be  supported  in 
the  Range  Header  by  RTSPDataSources  and  RTSPDataSinks  using  the  RTSPControlChannel. 

ptp-range  =  "ptp-clock"  "="  ptp-startTime  [  ptp-endTime  ] 

ptp-startTime  =  "start"  |  "now"  |  TmNStimestamp* 
ptp-endTime  =  "end"  |  "now"  |  TiriNStimestamp* 


*TmNSt  imestamp  format  is  defined  in  Chapter  22  Subsection  22.5.1.3.6. 

The  following  rules  shall  be  supported  for  the  PTP  time  range. 

•  If  a  ptp-endTime  is  specified,  then  the  ptp-endTime  shall  be  greater  than  the 
ptp-startTime. 

•  A  “start”  constant  shall  be  interpreted  as  the  earliest  MessageTimestamp  of  all 
available  TmNSDataMessages. 

A  “now”  or  “end”  constant  shall  be  interpreted  as  inclusive  of  the  latest 
MessageTimestamp  of  all  available  TmNSDataMessages  at  the  receipt  of  the 
request. 

•  Not  specifying  a  ptp-endTime  or  specifying  a  ptp-endTime  that  exceeds  the 
latest  MessageTimestamp  of  all  available  TmNSDataMessages  results  in  the 
RTSPDataSource  transmitting  data  from  the  ptp-startTime  to  the  last  available 
requested  TmNSDataMessage  and  then  continually  transmitting  received  requested 
TmNSDataMessages  until  one  of  the  following  conditions  occurs: 

o  The  ptp-endTime  is  specified  and  the  MessageTimestamp  of  a  received 
requested  TmNSDataMessage  is  equal  to  or  exceeds  the  specified  ptp- 
endTime; 

o  A  TEARDOWN  is  executed; 

o  The  TCP -based  RCDataChannel  is  closed; 

For  all  of  the  above  conditions  except  the  RCDataChannel  closure,  the 
RTSPDataSource  shall  transmit  an  End  of  Data  Indication  (see  Subsection  26.4.2.2) 
prior  to  closing  the  RCDataChannel. 

•  Requests  with  no  ptp-endTime  shall  remain  active  until  a  TEARDOWN  is 
executed. 

•  If  no  TmNSDataMessages  are  available,  the  DataSource  shall  return  a  status  code  of 
412  (“Precondition  Failed”)  except  in  the  case  where  the  ptp-startTime  is  set  to 
“start”  or  “end”  and  the  ptp-endTime  is  not  set. 

•  If  a  time  range  specification  does  not  satisfy  the  aforementioned  rules,  the 
RTSPDataSource  shall  return  a  status  code  of  457  (“Invalid  Range”). 


To  support  TmNSDataMessage’ s  native  Message  Timestamp  format,  RTSPDataSources 
and  RTSPDataSinks  implementing  the  RTSPControlChannel  shall  support  the  following 
modifications  to  RFC  2326,  Section  12.29  (“Range”): 

1 .  The  PTP  Time  Range  format  shall  be  supported; 
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2.  The  Network  Time  Protocol  and  Universal  Coordinated  Time  time  range  formats  may  be 
supported; 

3.  The  “time=”  option  may  be  supported  with  the  addition  of  the  PTP  time  range  format. 

Range  =  "Range"  l\#ranges-specif ier 

[  "time"  "="  utc-time  |  TmNStimestamp^  ] 

ranges-specif ier  =  npt-range  |  utc-range  |  smpte-range  |  ptp-range^ 


^  Bold  items  are  new;  the  remaining  items  are  defined  in  RFC  2326. 

If  the  RTSP  Range  header  is  not  specified,  then  data  shall  be  supplied  as  though  a 
“start”  constant  was  given  for  the  ptp-startTime,  an  “end”  constant  was  given  for  the 
ptp-endTime ,  and  no  value  for  the  “time”  option  was  given. 


The  RTSP  Range  header  represents  only  a  request  for  a  time  range,  and  standard  errors 
should  be  returned  when  requests  cannot  be  serviced  or  in-progress  connections  fail. 


NOT^^ 

Use  of  Society  of  Motion  Picture  and  Television  Engineers  (SMPTE) 
relative  timestamps  in  the  RTSP  Range  header  is  not  recommended.  The 
SMPTE  timestamps  are  intended  for  video  clips  and  the  format 
(“hours:minutes:seconds:frames. subframes”)  does  not  clearly  map  to  time 
range  selection  based  on  TmNSDataMessage  MessageTimestamp  values. 

NOT^^ 

The  inclusiveness  and  exclusiveness  of  range  intervals  is 
specified  in  Section  12.29  of  RFC  2326. 

RTSPDataSources  and  RTSPDataSinks  shall  interpret  ptp-st  art  Time  and  ptp- 
endTime  values  as  measurement  time,  not  as  message  time. 

NOT^^ 

The  start  and  end  time  values  must  be  interpreted  as  measurement  time  and  not 
message  time  in  order  to  ensure  all  requested  data  is  returned.  A  message  may 
contain  data  for  a  time  range,  not  just  a  single  time  as  specified  by  the 
message’s  MessageTimestamp. 

The  first  TmNSDataMessage  returned  for  a  specified  ptp- start  Time  shall  be  the 
requested  TmNSDataMessage  with  the  latest  MessageTimestamp  that  is  less  than  or  equal  to  the 

ptp- St  art  Time. 


If  the  ptp- St  art  Time  precedes  the  earliest  available  requested  TmNSDataMessage’ s 
MessageTimestamp,  the  earliest  requested  TmNSDataMessage  shall  be  the  first 
TmNSDataMessage  returned. 


26.4. 1.3  Bandwidth  and  Speed  Headers 

The  RTSP  Speed  header  shall  be  supported  by  RTSPDataSources  using  the 
RTSPControlChannel. 

The  RTSP  Speed  header  should  be  supported  by  RTSPDataSinks  using  the 
RTSPControlChannel. 
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For  the  RTSP  Speed  header,  normal  speed  (1.0)  shall  be  defined  as  the  rate  at  which 
TmNSDataMessage  MessageTimestamp  values  progress. 


NOTE^ 

Not  all  speeds  from  the  RTSP  Speed  header  are  required 

r 

to  be  supported. 

The  RTSP  Bandwidth  header  shall  be  supported  by  RTSPDataSources  using  the 
RTSPControlChannel. 

The  RTSP  Bandwidth  header  should  be  supported  by  RTSPDataSinks  using  the 
RTSPControlChannel. 

If  the  RTSP  Speed  and  Bandwidth  headers  are  not  specified,  then  data  shall  be  supplied 
as  fast  as  possible,  as  regulated  by  the  resources  between  the  RTSPDataSource  and  the 
RTSPDataSink. 

RTSPDataSinks  shall  not  specify  both  the  RTSP  Speed  and  Bandwidth  headers  in  the 
same  request. 

26.4.1.4  Request-Defined  Uniform  Resource  Indicator  (URI)  Syntax 

The  RTSP  methods  used  in  the  RTSPControlChannel  shall  use  the 
TmNS_Request_Defined_URI  to  request  specific  data  from  an  RTSPDataSource.  The 
TmNS_Request_Defined_URI  shall  use  the  generic  syntax  for  URIs  as  specified  in  Chapter  22  as 
specialized  below. 

TmNS_Request_Def ined_URI  = 

"rtsp://"  TmNShost  [  TmNShostport  ]  "/"  "TmNS"  "/"  TmNSversion  "/" 

[  TmNSlist  "/"  ]  [  TmNSdestIP  [  TmNSdestport  ]  "/"  ] 

[  TmNSplaybackopt  "/"  ]  [  TmNStimeopt  "/"  ] 

[  "/"  TmNSdeliveryDSCP  ] 


TmNShost 
TmNShost name 
TmNSdomainlabel 
TmNS top label 
TmNS IPv4 address 
TmNShostport 
TmNSdeliveryDSCP 


=  TmNShostname  |  TmNSIPv4address 
=  * (  TmNSdomainlabel  " . "  )  TmNStoplabel  [  " . "  ] 

=  TmNSalphanum  |  TmNSalphanum  * (  TmNSalphanum  |  )  TmNSalphanum 

=  ALPHA  I  ALPHA  * (  TmNSalphanum  |  )  TmNSalphanum 

=  1*DIGIT  1*DIGIT  1*DIGIT  1*DIGIT 

=  1*DIGIT 
=  1*DIGIT 


TmNSversion 


=  "1.0" 


TmNSlist 


=  ( l*TmNSmdidlist )  |  (1* (TmNSpdidlist  ">"  TmNSdeliverymdid) )  | 

( 1* (TmNSmeasidlist  ">"  TmNSdeliverymdid  "<"  TmNSdeliverypdid  )) 
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TmNSmdidlist 

=  1*(  TmNSmdid 

[  " 

TmNSmdid  ]  ) 

TmNSmdid 

=  1*DIGIT 

TmNSpdidlist 

=  1*(  TmNSmdidlist 

1*  ( 

TmNSpdid  [  TmNSpdid  ]  ) 

TmNSpdid 

=  1*DIGIT 

TmNSmeasidlist 

=  1*(  TmNSpdidlist 

1*  ( 

TmNSmeasid  TmNSmeasid  ] 

TmNSmeasid 

=  1*DIGIT 

TmNSdestIP 

=  1*DIGIT  1*DIGIT 

II  II 

1*DIGIT  1*DIGIT 

TmNSdestport 

=  1*DIGIT 

TmNSdeliverymdid 

=  1*DIGIT 

TmNSdeliverypdid 

=  1*DIGIT 

TmNSplaybackopt 

II 

II 

:  marked 

as  live  data  in  MessageFlags 

;  "p"  =  marked  as  playback  data  in  MessageFlags 

;  default  is  "p"  if  not  provided 

TmNStimeopt  =  "o"  |  "c"  ;  "o"  =  original  timestamps 

;  "c"  =  timestamps  based  on  RTSPDataSource  current  time 

;  default  is  "o"  if  not  provided 

TmNSalphanum  =  ALPHA  |  DIGIT 

All  numeric  fields  of  the  TmNS_Request_Defined_URI  shall  be  interpreted  as  decimal. 

The  TmNShost  and  optional  TmNShostport  values  shall  indicate  the  IPv4  address  and 
port  of  the  RTSPDataSource. 

The  optional  TmNSdeliveryDSCP  specifies  the  DSCP  marking  to  which  requested 
TmNSDataMessages  shall  be  sent.  If  the  TmNSdeliveryDSCP  is  not  specified,  the 
RTSPDataSource  shall  mark  all  delivered  IP  packages  with  the  “Best  Effort”  marking. 

A  TmNSlist  that  contains  a  TmNSmdidlist  shall  indicate  a  MessageDefinitionID  request 
type  according  to  Subsection  26.4.1.5.1.  A  request  that  does  not  include  the  TmNSlist  shall 
indicate  a  MessageDefinitionID  request  for  all  MessageDefinitionIDs. 

A  TmNSlist  that  contains  a  TmNSpdidlist  shall  indicate  a  PackageDefinitionID  request 
type  according  to  Subsection  26.4.1.5.2. 

A  TmNSlist  that  contains  a  TmNSmeasidlist  shall  indicate  a  MeasurementlD  request 
type  according  to  Subsection  26.4.1.5.3. 

TmNSmdid  values  separated  by  a  shall  indicate  a  request  for  an  inclusive  range  of 
MDIDs  between  the  first  and  last  TmNSmdid  values  specified. 
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TmNSpdid  values  separated  by  a  shall  indicate  a  request  for  an  inclusive  range  of 
PDIDs  between  the  first  and  last  TmNSpdid  values  specified. 

TmNSmeasid  values  separated  by  a  shall  indicate  a  request  for  an  inclusive  range  of 
MeasurementIDs  between  the  first  and  last  TmNSmeasid  values  specified. 


For  all  request  types: 


•  If  present,  the  TmNSdest  IP  TmNSdestport  value  shall  indicate  the  IPv4  address 
and  port  to  which  requested  TmNSDataMessages  shall  be  sent. 

•  If  present,  the  TmNSplaybackopt  value  indicates: 

o  The  PlaybackDataFlag  shall  be  set  to  I’bO  when  the  value  is  “1”; 
o  The  PlaybackDataFlag  shall  be  set  to  I’bl  when  the  value  is  “p”; 

If  the  TmNSplaybackopt  is  not  present,  the  PlaybackDataFlag  shall  be  set  to  I’bO. 


•  If  present,  the  TmNStimeopt  value  indicates: 

o  The  TmNSDataMessage  Message  Timestamps  shall  be  the  original  timestamp 
when  the  value  is  “o” 

o  The  TmNSDataMessage  Message  Timestamps  shall  be  based  on  the 
RTSPDataSource’s  current  time  when  the  value  is  “c” 
o  If  the  TmNStimeopt  is  not  present,  the  TmNSDataMessage  Message  Timestamps 
shall  be  the  original  timestamp. 

•  When  requesting  Packages  without  standard  PackageHeaders  to  be  delivered  using 
Packages  with  standard  PackageHeaders,  the  time  expressed  using  the  delivery 
MessageTimestamp  and  delivery  PackageTimeDelta  shall  be  equivalent  to  the  time 
expressed  by  the  requested  MessageTimestamp. 


NOTE 


As  noted  in  RFC  2068^,  “servers  should  be  cautious  about  depending  on  URI 
lengths  above  255  bytes  because  some  older  client  or  proxy  implementations 
may  not  properly  support  these  lengths.”  The  appropriate  error  status  code 
specified  in  RFC  2326  for  "Request -URI  Too  Large"  is  "414". 


26.4. 1 .5  Request  Types 

RTSPDataSources  shall  return  valid  TmNSDataMessages  based  on  the  particular  request 
type  as  described  in  the  following  sections. 

If  none  of  the  requested  MessageDefinitionIDs  are  defined  in  an  RCDataSource  ’s 
RCDataSource  list,  the  RCDataSource  shall  return  a  status  code  of  412  (“Precondition  Failed”). 


If  no  TmNSDataMessages  are  available  on  the  RTSPDataSource  for  all  requested 
MessageDefinitionIDs,  the  RTSPDataSource  shall  transmit  an  End  of  Data  Indication  (see 
Subsection  26.4.2.2)  prior  to  closing  the  RCDataChannel. 


NOTE 


Since  the  RTSPDataSource  returns  ALL  data  that  match  its  request  criteria, 
it  is  possible  that  the  combination  of  a  particular  request  and  data  present  at 
an  RTSPDataSource  will  result  in  duplicate  data  being  returned.  The 


^  Internet  Engineering  Task  Force.  “Hypertext  Transfer  Protocol  -  HTTP/1 . 1 .”  RFC  2068.  Obsoleted  by  RFC 
2616.  January  1997.  Retrieved  8  May  2017.  Available  at  https://datatracker.ietf.org/doc/rfc2068/. 
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possibility  of  this  data  duplication  can  be  reduced  or  eliminated  by 
generating  a  more  speeific  request. _ 


26.4.1.5. 1  MessageDefinitionID  Request  (TmNSmdid) 

RTSPDataSources  proeessing  a  MessageDefinitionID  request  shall  adhere  to  the 
following  requirements. 

•  All  TmNSDataMessages  matching  the  requested  MessageDefinitionlD(s)  within  the 
timeframe  speeified  shall  be  delivered. 

•  Delivered  TmNSDataMessages  shall  be  labeled  with  the  original 
MessageDefinitionID(  s ) . 

•  The  delivered  TmNSDataMessages  Message  Timestamp  value  is  governed  by  the 
presenee  or  absence  of  the  TmNStimeopt  value  in  the  TmNS_Request_Defined_URI. 

•  Delivered  TmNSDataMessages  shall  retain  the  ApplicationDefinedFields, 
MessageFlags,  and  StatusFlags  fields  from  the  original  TmNSDataMessages . 


26.4.1.5.2  PackageDefinitionID  Request  (TmNSpdid) 

RTSPDataSources  proeessing  a  PackageDefinitionID  request  shall  adhere  to  the 
following  requirements. 

•  Valid  TmNSDataMessages  shall  be  delivered  eontaining  the  original  Packages 
matching  the  requested  PackageDefinitionlD(s).  Instances  of  the  Packages  to  be 
delivered  may  be  refined  through  the  speeification  of  MessageDefinitionIDs; 
otherwise,  ALL  instanees  of  the  Packages  within  the  timeframe  speeified  shall  be 
delivered. 

•  Delivered  TmNSDataMessages  shall  be  labeled  with  the  MessageDefinitionID  set  to 
the  value  speeified  in  TmNSdeliverymdid. 

•  Delivered  TmNSDataMessages  shall  follow  the  requirements  in  Subseetion  26.5.4  for 
handling  MessageFlags  fields. 

•  Any  ApplicationDefinedFields  in  the  delivered  TmNSDataMessages  shall  indieate 
eonditions  on  the  RTSPDataSource  delivering  the  TmNSDataMessages,  not  the 
original  RTSPDataSource. 

26.4. 1.5.2. 1  PackageDefinitionID  Request  Standard  PackageHeader  Handling 

RTSPDataSources  proeessing  a  PackageDefinitionID  request  shall  deliver  all  requested 

Packages  from  original  Packages  that  use  the  standard  PackageHeader. 

26.4. 1 .5.2.2  PackageDefinitionID  Request  Non-Standard  PaekageHeader  Handling 

RTSPDataSources  proeessing  a  PackageDefinitionID  request  and  that  support  extraetion 

from  Packages  that  do  not  use  the  standard  PackageHeader  shall  deliver  all  requested  Packages 
from  original  Packages  that  do  not  use  the  standard  PackageHeader. 

26.4.1.5.3  MeasurementID  Request  (TmNSmeasid) 

RTSPDataSources  processing  a  MeasurementID  request  shall  adhere  to  the  following 
requirements. 

•  Valid  TmNSDataMessages  shall  be  delivered  containing  Packages  with  the 
MeasurementData  matehing  the  requested  MeasurementlD(s).  Instanees  of  the 
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MeasurementData  to  be  delivered  may  be  refined  through  the  specification  of 
MessageDefinitionIDs  and/or  PackageDefinitionIDs;  otherwise,  ALL  instances  of 
MeasurementData  within  the  timeframe  specified  shall  be  delivered. 

•  Delivered  TmNSDataMessages  shall  be  labeled  with  the  MessageDefinitionID  field  in 
the  TmNSDataMessageHeader  set  to  the  value  specified  in  TmNSdeliverymdid. 

•  Delivered  TmNSDataMessages  shall  contain  Packages  according  to  the 
PackageDefinition  corresponding  to  the  TmNSdeliverypdid. 

•  Delivered  TmNSDataMessages  shall  follow  the  requirements  in  Subsection  26.5.4  for 
handling  MessageFlags  fields. 

•  Any  ApplicationDefinedFields  in  the  delivered  TmNSDataMessages  shall  indicate 
conditions  on  the  RTSPDataSource  delivering  the  TmNSDataMessages,  not  the 
original  RTSPDataSource. 

•  A  requested  Package  containing  the  requested  MeasurementData  shall  have  one  and 
only  one  corresponding  delivery  Package. 

26.4. 1 .5.3. 1  MeasurementID  Request  Standard  PackageHeader  Handling 

RTSPDataSources  processing  a  MeasurementID  request  shall  adhere  to  the  following 

requirements. 

•  The  RTSPDataSource  shall  deliver  all  requested  MeasurementData  from  original 
Packages  that  use  the  standard  PackageHeader. 

•  For  each  original  Package  that  uses  the  standard  PackageHeader,  the  corresponding 
Package  in  the  delivered  TmNSDataMessage  shall  have  a  Package  Time  equal  to  the 
Package  Time  of  the  original  Package  according  to  the  PackageDefinition 
corresponding  to  the  TmNSdeliverypdid. 

26.4. 1 .5.3.2  MeasurementID  Request  Non-Standard  PackageHeader  Handling 

RTSPDataSources  processing  a  MeasurementID  request  and  that  support  extraction  from 

Packages  that  do  not  use  the  standard  PackageHeader  shall  adhere  to  the  following 
requirements. 

•  The  RTSPDataSource  may  deliver  some  or  all  requested  MeasurementData  from 
original  Packages  that  do  not  use  the  standard  PackageHeader. 

•  For  each  original  Package  that  does  not  use  the  standard  PackageHeader,  the 
corresponding  Package  in  the  delivered  TmNSDataMessage  shall  have  a  Package 
Time  equal  to  the  Message  Time  of  the  original  Package  according  to  the 
PackageDefinition  corresponding  to  the  TmNSdeliverypdid. 


NOT 


A  more  accurate  timestamp  can  be  used  through  a  custom  PackageHeader 
if  one  is  available;  however,  interoperability  should  still  be  maintained 
without  the  use  of  a  custom  PackageHeader  timestamp. 


26-12 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  26,  July  2017 


26.4.2  RTSP-Based  Data  Channel  (RTSPDataChannel) 

The  operation  of  the  RTSPDataChannel  shall  be  eontrolled  by  the  RTSPControlChannel 
as  speeified  in  Subseetion  26.4.1.  The  RTSPDataChannel  transport  protoeol  (TCP  or  UDP)  is 
specified  in  the  transport  header  of  the  DataRequest. 

RTSPDataChannel  messages  shall  use  the  standard  TmNSDataMessage  structure  and 
mechanisms  as  specified  in  Chapter  24. 

Upon  receipt  of  a  valid  SETUP  request,  an  RTSPDataSource  shall  open  the 
RTSPDataChannel  socket. 

Upon  receipt  of  a  valid  PLAY  request,  an  RTSPDataSource  shall  attempt  to  transmit 
requested  data  to  the  RTSPDataChannel  socket. 

Upon  receipt  of  a  TEARDOWN  request,  an  RTSPDataSource  shall  close  the 
RTSPDataChannel  socket. 

After  receiving  the  TEARDOWN  response,  an  RTSPDataSink  shall  close  the 
RTSPDataChannel  socket. 


NOTE^ 

Handling  data  loss  on  a  DataChannel  is  not  addressed 

r 

by  this  standard. 

26.4.2. 1  TCP-Based  RTSPDataChannel 

Prior  to  issuing  a  SETUP  request,  an  RTSPDataSink  shall  open  the  RTSPDataChannel 
socket.  The  RTSPDataSink  shall  execute  a  listen  on  the  socket  and  optionally  obtain  an 
ephemeral  TCP  port  number  (which  would  be  included  in  the  transport  header). 

Upon  receipt  of  a  SETUP  request,  an  RTSPDataSource  shall  execute  a  connect  on  the 
socket  (the  SETUP  request’s  transport  header  contains  the  transport  protocol  information). 

26.4.2.2  End  of  Data  Indication 

When  the  RTSPDataSource  is  ready  to  close  the  RTSPDataChannel,  it  shall  deliver  an 
End  of  Data  Indicator  to  the  RTSPDataSink. 

The  RTSPDataSource  may  set  the  EndOfDataFlag  in  the  TmNSDataMessageHeader  of 
the  last  TmNSDataMessage  prior  to  sending  the  last  TmNSDataMessage  to  the  RTSPDataSink. 
Alternatively,  or  if  no  TmNSDataMessages  have  been  sent,  the  RTSPDataSource  shall  deliver  a 
TmNSDataMessage  with  no  TmNSDataMessagePayload  and  the  following  values  in  the 
TmNSDataMessageHeader: 

•  Set  MessageElags  to  16’h0001,  which  sets  only  the  EndOfDataElag 

•  Set  MessageDefinitionID  to  32’ dO. 

•  Set  MessageDefinitionSequenceNumber  to  32’ dO. 

•  Set  MessageLength  to  32’d24. 

•  Set  MessageTimestamp  to  64’dO. 
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26.4.3  Reliability  Critical  (RC)  Delivery  Protocol 

The  RC  Delivery  Protocol  is  the  TmNS-specific  application-level  method  of  delivering 
TmNSDataMessages  via  TCP. 


NOTE 


The  RC  Delivery  Protocol  section  and  all  related  subsections 
specify  how  to  deliver  TmNSDataMessages  when  reliability  of  data 
delivery  is  more  important  than  low  latency  or  high  throughput. 


26.4.3.1  RC  Delivery  Protocol  Data  Channel  (RCDataChannel) 

RCDataSources  and  RCDataSinks  shall  support  the  RTSPDataChannel  as  defined  in 
Subsection  26.4.2. 

RCDataSources  shall  transport  TmNSDataMessages  to  the  RCDataSinNs  IP  address  and 
the  destination  port  specified  in  the  transport  header. 

26.4.3.2  RC  Delivery  Protocol  Control  Channel  (RCControlChannel) 

RCDataSources  and  RCDataSinks  shall  exchange  control  commands  and  parameters 

using  the  RTSPControlChannel,  as  defined  in  Subsection  26.4.1.  This  section  specifies 
additional  constraints  on  using  the  RTSPControlChannel  as  the  RCControlChannel. 

The  RTSP  transport  header  shall  specify  TCP,  which  shall  be  used  for  the  transport  of 
TmNSDataMessages  on  the  RCDataChannel. 

A  DataRequest  from  an  RCDataSink  shall  use  at  least  one  of  the  following  three  request 
types  as  specified  in  Subsection  26.4.1.5: 

•  MessageDefinitionID  request; 

•  PackageDefinitionID  request; 

•  MeasurementID  request. 

26.4.4  Request-Defined  Data  Channel 

This  section  is  a  placeholder  for  future  growth. 

26.5  TmNSDataMessage  Transfer  Rules 

DataSources  and  DataSinks  shall  comply  with  the  standard  TmNSDataMessage  structure 
and  mechanisms,  as  specified  in  Chapter  24.  DataSources  shall  adhere  to  the  following 
TmNSDataMessage  transfer  rules. 

1.  Multiple  sequences  of  TmNSDataMessages  that  contain  different 
MessageDefinitionIDs  may  be  sent  to  the  same  multicast  or  unicast  destination 
address. 

2.  Multiple  DataSources  shall  not  send  TmNSDataMessages  with  the  same 
MessageDefinitionID  to  the  same  destination  address  unless  the  multiple 
DataSources  synchronize  the  incrementing  of  the  MessageSequenceNumber  field  in 
accordance  with  the  sequence  number  convention  specified  in  Subsection  26.5.1. 

3.  Replicated  TmNSDataMessages  may  be  sent  to  multiple  destination  addresses 
provided  rule  2  above  is  not  violated. 
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NOT 


When  adding  Packages  to  the  acquisition  TniNSDataMessage  payload,  a 
DataSource  should  use  a  mechanism  taking  the  minimum  of  “maximum 
message  size”  and  “maximum  elapsed  time”  variables  to  determine  when 
to  send  a  complete  TmNSDataMessage  of  sampled  data. _ 


26.5.1  Sequence  Numbering  Convention 

Each  TmNSDataMessageHeader  contains  a  MessageSequenceNumber  field  whose 
value  increments  by  one  for  each  TmNSDataMessage  instance  in  a  sequence  of 
TmNSDataMessages.  The  MessageSequenceNumber  value  shall  wrap  to  zero  after  2^^  -  1. 

The  wrapping  of  the  MessageSequenceNumber  value  to  zero  shall  not  indicate  a  loss. 

For  DataSources  generating  TmNSDataMessages,  MessageSequenceNumber  values  are 
assigned  on  a  per-MessageDefinitionlD  basis. 

The  MessageSequenceNumber  value  shall  not  repeat  consecutively  or  be  generated  out 
of  order  for  a  particular  sequence  of  TmNSDataMessages,  including  when  two  or  more 
DataSources  generate  TmNSDataMessages  with  the  same  MessageDefinitionID . 

The  MessageSequenceNumber  field  for  a  TmNSDataMessage  sequence  shall  be  set  to 
zero  upon  one  of  the  following: 

•  The  power-up  or  reset  of  the  NetworkNode  generating  the  corresponding 
TmNSDataMessage  sequence; 

•  The  configuration,  reconfiguration,  or  reset  of  the  TmNSApp  generating  the 
corresponding  TmNSDataMessage  sequence; 

•  The  instantiation  of  a  Request-Defined  DataChannel  generating  the  corresponding 
TmNSDataMessage  sequence. 

26.5.2  Timestamp  Convention 

The  MessageTimestamp  value  of  a  given  TmNSDataMessage  shall  be  no  earlier  than  all 
of  the  acquisition  times  of  MeasurementData  samples  in  the  previous  TmNSDataMessage 
instance  in  the  sequence  of  TmNSDataMessages .  See  Subsection  26.5.1  for  the  description  of  a 
sequence  of  TmNSDataMessages. 

26.5.3  TmNSDataMessage  Fragmentation 

TmNSDataMessages  support  being  broken  up  into  multiple  fragments.  The 
MessageFragmentationFlags  of  the  TmNSDataMessageHeader  identify  how  to  reconstruct  a 
full  TmNSDataMessage .  All  fragments  of  a  TmNSDataMessage  shall  include  the  same  value  for 
the  MessageTimestamp  and  MessageFlags  fields  in  their  TmNSDataMessageHeader  with  the 
following  exception  for  the  MessageFragmentationFlags  bits: 

•  The  first  fragment  shall  set  the  MessageFragmentationFlags  bits  to  “2’bOl” 
{TmNSDataMessage  with  the  first  fragment); 

•  Each  middle  fragment  shall  set  the  MessageFragmentationFlags  bits  to  “2’ b  10” 
{TmNSDataMessage  with  a  middle  fragment); 

•  The  last  fragment  shall  set  the  MessageFragmentationFlags  bits  to  “2’bl  1” 
{TmNSDataMessage  with  the  last  fragment). 

Each  fragment’s  MessageSequenceNumber  field  value  shall  follow  the  sequence 
numbering  convention  as  described  in  Subsection  26.5.1. 
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26.5.4  Generating  TmNSDataMessases  from  Other  TmNSDataMessases  Convention 
DataSources  that  combine  data  from  multiple  TmNSDataMessages  into  a  new 
TmNSDataMessage  shall  bitwise-OR  the  following  DataSource-s^&cific  MessageFlags  from  the 
original  TmNSDataMessages  to  form  the  resultant  DataSource-s^&cific  MessageFlags: 

DataSourceHealthFlag 

DataSourceT  imeLockFlag 

DataSourceAcquiredDataFlag 

Any  ApplicationDefinedFields  in  the  transferred  TmNSDataMessages  shall  indicate 
conditions  on  the  DataSource  delivering  the  TmNSDataMessages,  not  the  original  DataSource 
(the  ApplicationDefinedFields  from  the  original  TmNSDataMessages  are  discarded). 
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CHAPTER  27 

RF  Network  Access  Layer 


27.1  Introduction 

This  chapter  defines  the  mechanisms  and  processes  for  managing  the  physical  layer  of 
radio  frequency  (RF)  links  within  the  RF  network.  The  network  implements  an  Open  Systems 
Interconnection  (OSI)  model  approach  (Figure  27-1)  to  data  transmission,  where  data  moves 
through  the  OSI  stack  from  the  application  layer  to  the  physical  layer,  from  physical  layer  to 
physical  layer  through  some  transmission  medium,  then  back  up  the  stack  to  another  application 
on  the  receiving  side.  Because  the  system  is  network-based,  transmissions  occur  in  bursts  that 
are  scheduled  as  data  arrives. 


OSI  Model 

Layer 

Data  Unit 

Function 

Examples 

Host 

Layers 

7.  Application 

Data 

High  Level  APIs,  including  resource  sharing,  remote  file 
access,  directory  services  and  virtual  terminals 

HTTP,  FTP,  SNMP,  SSH,  TELNET 

6.  Presentation 

Translation  of  data  between  a  networking  service  and 
an  application,  including  character  encoding,  data 
compression  and  encryption/decryption 

HTML,  CSS,  GIF 

5.  Session 

Managing  communications  sessions,  i.e.  continuous 
exchange  of  information  in  the  form  of  multiple  back- 
and-forth  transmissions  between  two  nodes 

RPC,  PAP,  SSL,  SQL 

4.  Transport 

Segments/Datagram 

Managing  communications  sessions,  i.e.  continuous 
exchange  of  information  in  the  form  of  multiple  back- 
and-forth  transmissions  between  two  nodes 

TCP,  UDP,  NETBEUI 

Media 

Layers 

3.  Network 

Packet 

Structuring  and  managing  a  multi-node  network, 
including  addressing,  routing  and  traffic  control 

IPv4  IPv6,  IPSec,  Apple  Talk,  ICMP 

2.  Data  Link 

Frame 

Reliable  transmission  of  data  frames  between  two 
nodes  connected  by  a  physical  layer 

PPP,  lEE  802.2  L2TP,  MAC,  LLDP 

IRIG  106 
Chapter  28 

1 .  Physical 

Bit 

Transmission  and  reception  of  raw  bit  streams  over  a 
physical  medium 

Ethernet  physical  layer,  DSL  USB,  ISDN,  DOCSIS 

Covered 
by  this 
chapter 

Figure  27-1.  OSI  Model  as  related  to  the  TmNS  RF  Network 


This  chapter  describes  the  low-level  waveform  content  (e.g..  Frequency,  Modulation, 
Framing,  etc.).  Chapter  28  focuses  on  access  to  and  management  of  the  RF  portion  of  a 
Telemetry  Network  Standard  (TmNS)-based  network.  Chapter  21  Appendix  21-B  describes  the 
bit  numbering,  bit  ordering,  and  byte  ordering  conventions  used  in  this  chapter. 

27.2  Radio  Access  Network  Concepts  and  Definitions 

27.2.1  Data  Link  Layer  Framing 

The  RF  network  provides  a  standards-based  Internet  Protocol  (IP)  network  (Internet 
Engineering  Task  Force  Request  for  Comment  (RFC)  79 C  and  RFC  2474^).  Layers  supporting 
this  IP  layer  are  unique  to  the  RF  network.  Figure  27-2  shows  an  overview  of  the  protocol  layers 
associated  with  sending  an  IP  packet  over  the  data  link  layer  and  RF  physical  interface.  The  IP 


'  Internet  Engineering  Task  Force.  “Internet  Protocol.”  RFC  791.  Updated  by  RFC  2474,  RFC  6864,  and  RFC 
1349.  September  1981.  Available  at  https://datatracker.ietf.org/doc/rfc791/. 

^  Internet  Engineering  Task  Force.  “Definition  of  the  Differentiated  Services  Field  (DS  Field)  in  the  IPv4  and  IPv6 
Headers.”  RFC  2474.  Updated  by  RFC  3260  and  RFC  3168.  December  1998.  Retrieved  18  April  2017.  Available 
at  https  ://datatracker.  ietf  org/doc/rfc2474/. 


27-1 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  27,  July  2017 


packets  are  referred  to  as  RF  media  access  control  (MAC)  service  data  units  (MSDUs)  and  are 
comprised  of  complete  IP  packets  containing  user  data.  The  MSDUs  are  placed  into  payload 
blocks  with  aggregation  and  fragmentation  performed  to  meet  the  maximum  transmission  unit  of 
the  RF  channel.  The  length-limited  payload  blocks  are  separated  into  RF  MAC  frames  and  link 
layer  header  information  is  added.  Forward  error  correction  is  added  to  the  RF  MAC  frames  to 
create  low-density  parity-check  (LDPC)  blocks  suitable  for  transmission  over  the  RF  link. 

Details  of  the  higher  levels  of  this  protocol  are  covered  in  Chapter  28. 


Figure  27-2.  Data  Link  Layer  Framing  Overview 


On  the  receiving  end  of  the  RF  link,  the  physical  layer  recovers  the  transmitted  bitstream 
by  decoding  and  concatenating  codeblocks  arriving  in  the  transmission  opportunity’s  (TxOp’s) 
time  slots.  Each  decoded  codeblock  contains  one  MAC  frame.  These  RF  MAC  frames  contain 
complete  IP  packets  or  an  IP  packet  composed  of  multiple  MSDU  fragments.  Chapter  28 
describes  MSDUs  in  more  detail. 

When  a  link  layer  frame  is  constructed  for  transmission  in  the  process  described  here,  the 
completed  link  layer  frame  sent  shall  not  exceed  the  remaining  portion  of  the  current  TxOp. 

27.2.2  RF  Media  Access  Control  Laver 

The  RF  MAC  layer  is  responsible  for  providing  access  to  the  physical  media  (i.e.,  the 
wireless  RF  network).  On  the  transmission  side,  it  is  responsible  for  framing  IP  packets  for 
physical  transmission  (adding  in  the  layer-2  hardware  addresses  for  the  source/destination  pair  of 
the  link).  On  the  receive  side  it  is  responsible  for  validating  the  checksum  sent  with  each  packet 
(known  as  the  frame  check  sequence  [FCS],  Subsection  27.2.7)  and  de-framing  the  received 
packet. 

27.2.3  Epoch  Structure 

An  epoch-based  scheme  is  used  to  separate  transmission  signals  over  a  time-shared 
medium.  The  RE  network  implements  an  epoch-based  transmission  scheduling  scheme  to 
provide  an  efficient  utilization  over  a  shared  bandwidth.  Eink  management  messages  support 
dynamic  adjustment  of  the  epoch  schedule  being  utilized  by  components  comprising  an  RE 
network. 


27-2 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  27,  July  2017 


27.2.4  Transmission  Opportunities 

A  TxOp  is  an  allocated  window  in  time  during  which  a  radio  can  transmit  over  its 
associated  RF  interfaee.  The  TxOp  contains  a  frequency,  a  start  time  and  a  stop  time  that  is 
relative  to  the  epoch,  and  a  timeout  field  that  indicates  the  number  of  consecutive  epochs  that  the 
TxOp  is  valid  for.  The  frequency  associated  with  the  TxOp  is  the  carrier  frequency  at  which  the 
transceiver  shall  transmit  for  the  duration  of  the  TxOp.  At  the  stop  time,  the  transceiver  remains 
tuned  to  the  TxOp’s  carrier  frequeney  in  order  to  reeeive  incoming  transmissions  at  the 
frequency.  The  epoch  is  settable  to  a  number  of  discrete  times  during  radio  initialization. 

27.2.5  Timing 

The  RF  link  management  and  all  radios  under  its  control  shall  have  their  cloeks 
synchronized.  The  timing  of  access  to  the  RF  media  shall  be  synchronized  to  and  match  the 
timing  with  the  management  layer  described  in  Chapter  22.  The  format  of  the  time  in  RF 
network  messages  is  defined  in  Chapter  24. 

27.2.6  Radio  Link  State  Parameters 

Operating  parameters  of  a  radio  shall  be  stored  to  maintain  communications  with  RF  link 
management  after  a  power  interruption  or  software-initiated  reset.  Parameters  to  be  stored 
include,  as  a  minimum,  the  operating  frequency  of  the  radio,  the  TxOp  allocations  that  contain  a 
non-expiring  timeout  setting,  and  the  heartbeat  value. 

27.2.7  Frame  Check  Sequence 

The  FCS  contained  at  the  end  of  an  RF  MAC  frame  shall  serve  as  a  link  layer  error- 
cheeking  mechanism.  The  FCS  generation  and  verification  is  described  in  Subsection  27.5.5. 

27.3  Physical  Layer 

The  physical  layer  focuses  on  describing  the  operating  bands,  waveform  modulation/ 
demodulation  characteristics,  carrier  stability  and  synchronization/acquisition  eharaeteristics,  and 
coding/deeoding  techniques.  The  TmNS  system  provides  the  capability  of  the  range  to  support 
multiple  concurrent  test  missions  on  one  or  more  integrated  Network  Enhanced  Telemetry 
frequency  channels.  The  frequency  channels  available  for  use  in  a  TmNS-based  RF  network  are 
as  defined  in  Subseetion  27.3.1.2.  Allowable  adjacent  channel  interference  for  transmissions  is 
defined  in  Subsection  27.3.2.  Each  transmission  is  performed  as  diserete  bursts  within  start  and 
stop  times  that  are  provisioned  within  a  configured  epoch  time  by  an  external  configuration  file 
and/or  RE  link  management  as  defined  in  Chapter  28. 

Transmissions  between  radios  on  test  articles  (TAs)  and  those  contained  in  the  ground 
network  shall  use  the  same  carrier  frequency  in  both  directions.  Single  carrier  frequency  usage  is 
supported  by  employing  a  time-domain  duplex  channel  access  method.  In  this  method  radios  use 
re-occurring  epoch-based  transmissions  defined  by  start  and  stop  times  that  are  provisioned  by 
RE  link  management. 

27.3.1  Data  Rates  and  Spectrum 

27 .3 . 1 . 1  Radio  Air  Data  Rates 

The  data  rates  and  link  performance  in  terms  of  packet  loss  rate  (PER)  stated  below  are 
provided  based  on  1000-byte-long  Ethernet  packet  (see  Appendix  27- A  for  additional  details). 
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Assuming  the  codeblock  error  events  to  be  independent,  the  relation  between  codeblock  error 
rate  (CBER)  and  PLR  is  then  given  by  CBER  =  1  -  sqrt(l  -  PER).  Eor  example,  for  a  PER  of  1 
X  10'"^,  the  corresponding  CBER  is  5  x  10'^. 

Subsection  21 3.222  details  the  air  data  rates  that  radios  shall  comply  with  in  order  to 
ensure  interoperability. 


Rate  requirements  can  be  viewed  from  various  aspects.  When  viewed  from  an  OSI  7- 
layer  protocol  stack  perspective,  the  RE  communications  link  is  at  layer-2.  This  implies  that  all 
overhead  affiliated  with  layer-3  through  layer-7,  including  any  IP  and  High  Assurance  Internet 
Protocol  Encryptor  (HAIPE)  headers,  are  regarded  as  user  data.  The  effective  PER  is  referenced 
to  a  mean  packet  size  and  is  described  in  Appendix  27- A. 


NOTE 


The  air  data  rates  are  derived  from  a  model  that  assumes  a  certain  IP 
packet  distribution  such  that  the  airborne  network  and  throughput 
goals  are  met.  Details  concerning  how  to  get  from  IP  data  payload 
rate  to  the  air  data  rate  are  in  Appendix  27-A. 


27 . 3 . 1 . 2  B  and  of  Operation 

The  center  frequencies  shall  be  selectable  from  4800-4994  megahertz  (MHz).  Center 
frequency  selections  are  available  in  250-kilohertz  (kHz)  steps.  The  designated  center 
frequencies  for  use  within  a  TmNS-based  system  are  4900  MHz  and  4922  MHz. 

27.3.2  Regulatory  Specifications,  Spectral  Mask 

27.3.2. 1  SOQPSK-TG  Single-Carrier  Waveform  -  Spectral  Mask 

The  RE  emission  spectral  mask  defined  in  Chapter  2  shall  be  adopted  for  the  single¬ 
carrier  waveform  for  shaped  offset  quadrature  phase  shift  keying  (SOQPSK)-TG.  Peak 
waveform  power  density  for  the  SOQPSK-TG  waveform  is  estimated  to  be  -25  decibels  relative 
to  the  carrier  (dBc)/30  kHz  using  the  equation  in  Chapter  2  Appendix  2-A  with  20  Mbps,  K 
=  -61,  and  m  =  4. 

M(/)=  -61  +  9mogR-imog\f-fA-,  \f-fc\>S 


NOTE 


Eigure  27-3  shows  a  simulated  SOQPSK-TG  waveform  and  overlay  with 
single-carrier  spectral  mask.  The  power  spectra  was  calculated  for  20-Mbps 
channel  bit  rate  and  compared  with  the  continuous  stream  power  spectra  for  a 
resolution  bandwidth  of  30  kHz.  It  was  measured  during  the  steady  power 
condition  during  a  burst  transmission. 
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iNET  Wavefoin  PSD  with  Spectral  Mask 


Figure  27-3.  Example  Waveform  PSD  with  Spectral 
Mask  Overlay 


27.3.2.2  SOQPSK-TG  Single-Carrier  Waveform  -  Bandwidth 
27.3.2.2.1  Occupied  Bandwidth 

The  SOQPSK-TG  single-carrier  waveform  characteristics  are  defined  in  Chapter  2.  The 
waveform  operating  bands  are  defined  in  Subsection  27.3.1.2.  The  occupied  bandwidth  is 
defined  to  be  the  99%  power  bandwidth,  which  for  SOQPSK-TG  is  calculated  to  be  15.6  MHz 
for  an  air  channel  rate  of  20  Mbps  based  on  Table  A-2,  Appendix  2-A. 

2  7. 3. 2.2.2  Air  Information  Bit  Rate 

With  the  Rb  fixed  at  20  Mbps,  the  air  information  bit  rate  is  13.3  Mbps  due  to  the  2/3 
LDPC  encoding. 

27.3.2.2.3  Guard-Bands  and  Band  Edge  Spurious  Level 

Spurious  emissions  are  absolute  limited  to  -25  dBm.  Guard-bands  are  identified  via 
Adjacent  Channel  Interference  criteria  as  defined  in  IRIG-106.  See  Chapter  2  Appendix  2-A. 

27.3.2.3  Multiple-Carrier  Waveform  -  Spectral  Mask 
This  section  is  a  placeholder  for  future  growth. 

27.3.2.4  Multiple-Carrier  Waveform  -  Bandwidth 
This  section  is  a  placeholder  for  future  growth. 
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27.3.3  Carrier  and  Clock  Frequency  Error,  Phase  Noise,  Spurs,  Receiver  Sensitivity 

27.3.3.1  SOQPSK-TG  Single-Carrier  Transmission 

27.3.3.1.1  Carrier  Frequency  Error 

The  radio  carrier  frequency  error  shall  be  bounded  by  ±5  parts  per  million  (ppm).  This 
corresponds  to  a  frequency  shift  of  ±25  kHz  at  a  transmission  frequency  of  5  gigahertz  (GHz). 

27.3.3.1.2  Transceiver  Phase  Noise 

Random  transceiver  phase  noise  at  the  transceiver  RF  output  port,  L(\Af\ )  in  dBc/Hz, 
shall  not  exceed  the  mask  limits  in  Table  27-1.  The  parameter  I  d/l  is  offset  from  the  carrier 
frequency  and  Rb  is  the  radio  air  channel  bit  rate  in  bits  per  second.  The  total  power  in  discrete 
(deterministic)  spurious  noise  components  shall  not  exceed  -30  dBc  in  the  same  frequency  offset 
range.  Compliance  with  the  mask  shall  be  checked  while  the  transceiver  is  producing  an  un¬ 
modulated  continuous  carrier  signal  at  both  the  minimum  and  maximum  power  levels  available 
for  modulated  burst  transmission. 


Table  27-1.  Transceiver  Phase  Noise  Mask 

dBc/Hz 

Frequency  Offset 

-30  dBc/Hz 

10  Hz 

-60  dBc/Hz 

100  Hz 

-70  dBc/Hz 

1  kHz 

-80  dBc/Hz 

10  kHz 

-90  dBc/Hz 

100  kHz 

-100  dBc/Hz 

1  MHz 

The  upper  limit  of  the  single  sideband  phase  noise  described  by  Table  27-1  is  depicted  in 
Figure  27-4. 
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27.3.3.1.3  Frequency  Error  Attributed  to  Doppler 

The  radio  transmission  frequency  error  seen  at  the  receiver  due  to  Doppler  effects  shall 
be  bounded  by  +2.5  ppm.  This  corresponds  to  a  frequency  error  spread  of  +12.5  kHz  at  a 
transmission  frequency  of  5  GHz.  This  frequency  shift  due  to  Doppler  effects  is  budgeted  for  the 
combined  total  of  relative  motion  between  two  transceivers,  either  between  a  stationary 
transceiver  and  a  moving  transceiver  or  between  two  moving  transceivers.  The  maximum 
Doppler  shift  for  a  set  of  example  carrier  frequencies  is  provided  in  Table  27-2  below. 


Table  27-2.  Maximum  Doppler  Shift 

Carrier  Frequency 

Maximum  Doppler  Shift  (+2.5  ppm) 

5  GHz 

12.5  kHz 

2.4  GHz 

6  kHz 

1.5  GHz 

3.75  kHz 

27.3.3.1.4  Symbol  Clock  Frequency  Error 

The  radio  transmission  symbol  clock  frequency  error  shall  be  bounded  by  +5  ppm. 

27.3.3.1.5  Transmission  Time  Accuracy 

The  radio  transmission  shall  begin  within  ±1  ps  of  the  intended  transmission  time. 


27.3.3.2  Multiple-Carrier  Transmission 


This  section  is  a  placeholder  for  future  growth. 


NOTE^ 

Multiple-carrier  waveform  spectrum  is  subject  to 

A 

ongoing  evaluation. 

27.4  RF  Burst  Format 

The  RF  burst  format  is  displayed  in  Figure  27-5. 


Figure  27-5.  RF  Burst  Format 

The  RF  burst  format  contains  a  preamble,  an  attached  synchronization  monitor  (ASM),  a 
codeblock  frame,  and  2  bits  of  trailing  zeros  to  return  the  encoder  to  a  flushed  state.  A 
codeblock  frame  may  contain  an  integer  multiple  of  LDPC  codeblocks,  from  a  minimum  of  1  up 
to  a  maximum  of  16.  The  number  of  LDPC  codeblocks  in  a  codeblock  frame  are  specified 
during  configuration. 

27.4.1  Physical  Layer  Modulation 

A  single-carrier  SOQPSK  modulation  scheme  shall  be  used.  The  waveform  shall  be 
implemented  as  defined  in  Chapter  2  Subsection  2. 4. 3. 2. 
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27.4.2  Preamble 

For  the  SOQPSK-TG  waveform  adopted  for  the  single-carrier  physical  layer  modulation 
format,  the  burst  preamble  is  formed  as  described  in  Figure  27-6.  Starting  from  a  flushed  trellis 
(00  state),  alternate  the  in-phase  (I)  and  quadrature  (Q)  bits  as  follows. 


In-phase;  62fc  =  1, 0, 1,  0, 1,  0, 1, 0  T 

-  for  K  =  I 

Quadrature;  62fc-|-l  =  1?  0)  Ij  0?  Ij  0?  0  , 

_  repeated  128/16  =  8  times 

Figure  27-6.  SOQPSK-TG  Burst  Preamble 


This  leads  to  a  period- 16  ternary  symbol  sequence  {uk}  with  the  following  structure. 

(-1-1,  +1,  -1-1,  +1,  +1,  +1,  +1,0,  -1,  -1,  -1,-1,  -1,  -1,  -1, 0, . . .) 

7  +ls  7  -Is 

For  a  128-bit  preamble,  there  shall  be  8  full  cycles  of  the  period- 16  preamble  present  in 
the  transmitted  SOQPSK-TG  waveform. 

27.4.3  Attached  Synchronization  Marker 

For  codeblock  frame  synchronization,  a  64-bit  ASM  (64’h0347  76C7  2728  95B0)  shall 
be  used  for  each  codeblock  frame.  This  burst  synchronizer  can  also  be  used  for  resolving  phase 
ambiguity  at  the  receiver. 

27.4.4  Pseudo-Randomization 

The  pseudo-random  sequence  shall  be  generated  using  the  following  polynomial:  h(x)  = 
+x’  +  x^  +  x^  +  1.  It  has  a  maximal  length  of  255  bits  with  the  first  40  bits  of  the  pseudo¬ 
random  sequence  from  the  generator  as40’bllll  1111  0100  1000  0000  1110  1100  0000  1001 
1010.  The  sequence  begins  at  the  first  bit  of  the  first  codeblock  in  a  codeblock  frame,  and  the 
sequence  repeats  after  255  bits,  continuing  repeatedly  until  the  end  of  the  last  codeblock  in  a 
codeblock  frame.  The  leftmost  bit  of  the  pseudo-random  sequence  is  the  first  bit  to  be  exclusive- 
ORed  with  the  first  bit  of  the  codeblock.  The  pseudo-randomizer  shown  in  Figure  27-7  is 
described  in  more  detail  in  Chapter  2,  Appendix  2-D. 
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Figure  21-1 .  Pseudo-Randomizer 


At  the  transmitter,  a  set  of  codeblocks  in  a  codeblock  frame  shall  be  randomized  by 
exclusive-ORing  the  first  bit  of  the  first  codeblock  with  the  first  bit  of  the  pseudo-random 
sequence,  followed  by  the  second  bit  of  the  first  codeblock  with  the  second  bit  of  the  pseudo¬ 
random  sequence,  and  so  on.  The  pseudo-randomizer  resets  to  the  initial  state  of  “all  ones”  at 
the  start  of  each  codeblock  frame  for  each  ASM  period. 

At  the  receiver,  each  original  codeblock  of  a  codeblock  frame  shall  be  reconstructed 
using  the  same  pseudo-random  sequence.  After  locating  the  ASM,  the  pseudo-random  sequence 
is  exclusive- ORed  with  the  received  data  bits  immediately  following  the  ASM.  The  pseudo¬ 
randomizer  resets  to  the  initial  state  of  “all  ones”  at  the  start  of  each  received  codeblock  frame 
for  each  ASM  period. 

The  ASM,  depicted  in  Figure  27-8,  is  not  randomized.  Randomization  ensures  that  coded 
symbols  are  spectrally  near-white,  thus  allowing  each  ASM  to  provide  synchronization  for  a  set 
of  randomized  codeblock(s)  in  a  codeblock  frame. 


Figure  27-8.  Pseudo-Randomization  Block  Diagram 


At  the  transmitter  side,  the  ASM  is  prepended  to  each  set  of  randomized  codeblocks  as 
the  synchronization  header.  At  the  receiver  side,  the  ASM  is  detected  and  located  in  the  received 
data  stream.  Then  the  pseudo-random  sequence  is  exclusive-ORed  with  the  data  bits 
immediately  following  the  ASM  location. 
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27.4.5  Low-Density  Parity-Check 

Each  LDPC  codeblock  shall  contain  one  512-byte  RE  MAC  frame  or,  if  the  RE  MAC 
frame  is  not  512  bytes,  padding  bytes  with  yalues  of  zero  shall  be  added  after  the  ECS  to  fill  a 
512-byte  codeblock  before  encoding. 

The  Eorward  Error  Correction  code  shall  be  an  EDPC  code  as  specified  in  CCSDS  131.1- 

0-2.3 


A  reference  implementation  of  the  EDPC  is  ayailable  from  Chapter  2  Appendix  2-D 
using  the  yalues  r=2/3  and  k=4096. 

27.5  RF  Media  Access  Control  Frame  Structure 

The  MAC  frame  structure  determines  what  RF  transmissions  are  receiyed  by  a  receiying 
radio.  The  RF  MAC  filters  receiyed  traffic,  accepting  only  those  transmissions  that  the  radio  is 
interested  in  receiying. 

The  network  message  headers  for  RF  MAC  control  frames  contain  the  destination, 
source,  and  a  sequence  number.  The  destination  address  is  either  an  RF  MAC  address  of  the 
destination  radio  or  an  RF  multicast  address  that  specifies  the  multicast  group  of  one  or  more 
receiying  radios.  The  source  address  is  always  the  RF  MAC  address  of  the  transmitting  radio.  A 
sequence  number  is  included  to  allow  for  duplicate  rejection  and  identification  of  a  specific  link 
layer  command. 

Each  RF  MAC  frame  shall  contain  an  RF  MAC  header,  a  CCMP  header,  an  RF  MAC 
payload,  a  Message  Integrity  Code  (MIC)  field,  and  a  32-bit  FCS.  The  RF  MAC  frame  format  is 
depicted  in  Figure  27-9. 


RFMAC 

HEADER 

CCMP 

HEADER 

RF  MAC  PAYLOAD 

MIC 

FCS 

Figure  27-9.  RF  MAC  Frame  Structure 


The  RF  MAC  frame  processing  shall  proceed  with  an  equiyalent  of  the  following  steps. 

1 .  Codeblock  is  receiyed,  and  the  EDPC  is  decoded. 

2.  For  successfully  decoded  FDPCs,  the  link  layer  processing  checks  the  FCS. 

3.  The  RF  MAC  frames  with  correct  FCS  fields  are  further  inspected  for  the  Destination 
Address  field  in  the  RF  MAC  header. 

4.  Further  processing  is  carried  out  for  RF  MAC  frames  that  contain  a  Destination 
Address  for  which  the  receiying  radio  has  been  assigned  to  listen. 

a.  If  the  Protected  Frame  bit  indicates  decryption  is  needed,  the  link  layer 
processing  then  decrypts  the  frame  and  checks  the  MIC. 

b.  Unencrypted  and  successfully  decrypted  RF  MAC  payloads  are  processed  as 
network  data  as  described  in  Chapter  28. 


^  Consultative  Committee  for  Space  Data  Systems.  Low  Density  Parity  Check  Codes  for  Use  in  Near-Earth  and 
Deep  Space  Applications.  Standard  CCSDS  131. 1-0-2-S.  September  2007.  Rescinded.  Retrieved  30  June  2015. 
Available  at  http://public.ccsds.org/publications/archive/131xlo2e2s.pdf. 
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Rejection  at  any  of  the  steps  described  above  does  not  require  further  processing,  and  the 
RF  MAC  frame  shall  be  discarded;  however,  statistics  for  discarded  RF  MAC  frames  shall  be 
maintained  as  described  in  Chapter  25. 

27.5.1  RF  MAC  Header 

The  RF  MAC  header  is  64  bits  long  and  shall  consist  of  the  fields  as  shown  in  Figure 

27-10. 
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Reserved 
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Version 
(2  bits) 

Reserved 
(6  bits) 

Protectee 
Frame 
(2  bits) 

Destination  Address  (DA) 

(16  bits) 

Source  Address  (SA) 

(16  bits) 

Reserved 
(3  bits) 

Length  of  MAC  payload  in  MAC  frame 
(13  bits) 

Figure  27-10.  RF  MAC  Header  Structure 


NOTE 


In  the  future,  it  may  be  desirable  to  have  a  MAC  frame  that  spans  1- 
16  codeblocks.  To  provide  for  this  future  capability,  the  Length 
field  in  the  MAC  header  is  large  enough  to  accommodate  values  up 
to  8192,  i.e.,  [0  ..  8124]  bytes  (maximum  of  16  codeblocks). 


27 .5 . 1 . 1  Frame  Control 

The  Frame  Control  field  of  the  RF  MAC  header  is  16  bits  in  length  and  shall  contain  the 
fields  defined  in  Subsection  27.5.1.1.1  through  Subsection  27.5.1.1.4. 

27.5.1.1.1  Reserved  Field  1  (6  bits) 

This  field  is  reserved  for  future  use.  All  bits  shall  be  set  to  zero  (6’bOOOOOO)  on 
transmission;  ignored  on  reception. 

27.5.1.1.2  Version  Field  ( 2  bits ) 

This  field  specifies  the  version  of  the  RF  MAC  frame.  This  chapter  defines  the  RF  MAC 
Frame  Version  1  (2’bOO). 

27.5.1.1.3  Reserved  Field  2  (6  bits) 

This  field  is  reserved  for  future  use.  All  bits  shall  be  set  to  zero  (6’bOOOOOO)  on 
transmission;  ignored  on  reception. 
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27.5.1.1.4  Protected  Frame  Field  ( 2  bits ) 

This  field  indicates  whether  or  not  the  RF  MAC  payload  is  encrypted.  Transmitters  shall 
set  this  field  according  to  its  configuration  provided  through  a  Metadata  Description  Language 
file.  Receivers  shall  use  this  field  to  determine  how  to  process  the  RF  MAC  payload. 

This  chapter  defines  the  following  versions: 

•  2’bOO  -  Unprotected  Frame 

•  2’bOl  -  Advanced  Encryption  Standard  (AES)  -  Counter  with  Cipher  Block 
Chaining  Message  Authentication  Code  mode  Protocol  (CCMP) 

•  2’blO-  Reserved  for  future  use 

•  2’bl  1  -  Reserved  for  future  use 

27 . 5 . 1 . 2  Destination  Addres  s 

This  16-bit  field  contains  the  RF  MAC  address  of  the  next  hop  destination  radio  or 
multicast  RF  MAC  address.  Additional  details  of  RF  MAC  addressing  are  found  in  Chapter  28. 

27.5.1.3  Source  Address 

This  16-bit  field  contains  the  RF  MAC  address  of  the  transmitting  radio.  Additional 
details  of  RF  MAC  addressing  are  found  in  Chapter  28. 

27.5.1.4  Reserved 

This  3-bit  field  is  reserved  for  future  use.  On  transmission,  the  transmitting  radio  shall 
set  this  field  to  3’bOOO.  On  reception,  the  receiving  radio  shall  ignore  these  bits. 

27.5.1.5  Eength 

This  13-bit  field  contains  the  length  in  bytes  of  the  RF  MAC  payload  in  the  RF  MAC 
frame.  This  value  does  not  include  the  length  of  the  RF  MAC  header  or  the  associated  FCS. 

The  valid  range  for  this  field  is  [0  ..  500]. 

The  Eength  field  in  the  RE  MAC  header  is  used  to  separate  valid  bytes  from  padding 
bytes  in  the  RE  MAC  frame.  If  there  are  valid  bytes  in  the  RE  MAC  payload,  the  first 
fragmentation/packing  sub-header  (EPSH)  is  checked  for  the  priority  and  length  of  the 
subsequent  MSDU_block.  The  EPSH  and  its  MSDU_block  are  then  passed  for  further 
processing.  While  valid  bytes  remain  in  the  RE  MAC  payload,  the  next  EPSH  is  checked  and 
processing  continues  as  above.  Any  padding  bytes  are  discarded.  Processing  of  bits  within  the 
RE  MAC  payload  are  described  in  detail  in  Chapter  28. 

27.5.2  CCMP  Header 

AN  8-byte  CCMP  header  shall  follow  immediately  after  the  RE  MAC  header. 
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When  AES  encryption  is  employed,  AES-CCMP  encryption  shall  be  used  to  generate  the 
CCMP  header,  the  encrypted  payload,  and  the  MIC.  The  CCMP  header,  encryption,  and  MIC 
shall  follow  the  recommendations  described  in  NIST  SP  800-97.^ 

When  AES  encryption  is  not  employed,  the  CCMP  header  field  shall  be  set  to  zero 
(64’hOOOO  0000  0000  0000)  for  transmission;  ignored  on  reception. 

27.5.3  RE  MAC  Payload 

The  payload  shall  be  encrypted  or  unencrypted  according  to  the  Protected  Erame  field  of 
the  RE  MAC  header.  The  length  of  the  payload  shall  be  in  the  range  of  0-500  bytes. 

If  encryption  is  enabled,  the  AES-CCMP  process  shall  generate  the  CCMP  header. 

27.5.4  Message  Integrity  Code 

An  8-byte  MIC  is  used.  Details  of  the  MIC  are  described  in  NIST  SP  800-97. 

When  AES  encryption  is  not  employed,  the  MIC  field  shall  be  set  to  zero  (64’hOOOO)  for 
transmission;  ignored  on  reception. 

27.5.5  Erame  Check  Sequence  Eield 

A  32-bit  ECS  shall  be  computed  over  the  entire  MAC  frame,  including  the  MAC  header 
and  the  entire  MAC  payload  (encrypted  or  unencrypted),  using  the  IEEE  802.3^  CRC-32 
polynomial  below: 

x26-|-  x23+  x'^-l-x'^-l-  X**-|-  X*°-|-  X^-|-  X^-|-X^-|-  X^^-l-  X^+  X-l-1. 

27.6  Power  Transients 

Eor  RE  power  transients  within  a  TxOp  allocation,  a  radio  shall  become  capable  of  full- 
power  transmission  25  microseconds  (ps)  after  the  radio  finishes  receiving  a  transmission 
intended  for  it.  Once  a  radio  has  ceased  transmitting,  the  radio  shall  disable  its  transmission  and 
be  ready  within  15  ps  to  receive  a  transmission  from  another  radio  using  default  modulation 
modes  and  burst  rates.  A  radio  shall  be  capable  of  receiving  consecutive  symbol-synchronous 
burst  sequences  with  no  time  separation  between  burst  sequences.  Eigure  27-11  provides  an 
example  TxOp  timing  allocation  diagram  that  highlights  the  allowable  transition  times  for  the 
transceiver  to  transition  between  receiving  and  transmitting  and  vice  versa.  Any  ramp-up  or 
ramp-down  times  associated  with  a  radio  shall  occur  during  the  TxOp  allocation  of  the  radio. 
When  a  radio  is  not  executing  a  TxOp,  it  shall  be  listening  for  RE  transmissions  from  other 
radios. 


*  National  Institute  of  Standards  and  Technology.  “Establishing  Wireless  Robust  Security  Networks:  A  Guide  to 
IEEE  802.1  li.”  SP  800-97.  May  be  superseded  by  update.  Retrieved  19  April  2017.  Available  at 
http://nvlr)ubs.nist.gov/nistt)ubs/Legacv/SP/nistst)ecialr)ublication800-97.pdf. 

^  Institute  of  Electrical  and  Electronics  Engineers.  IEEE  standard  for  ethernet.  IEEE  Std  802.3-2012.  New  York: 
Institute  of  Electrical  and  Electronics  Engineers,  2012. 
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Maximum  time  to  transmit 
first  burst:  Tom  <=  25  uS 


Maximum  time  to  disable 
transmission:  Totf  <=  15  uS 
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Figure  27-11.  Example  TxOp  Timing  of  a  Single  TxOp  Allocation 


In  the  example  provided  in  Figure  27-11,  the  transmitting  radio  turned  off  its  transmitter 
prior  to  the  end  of  its  TxOp  allocation.  If  no  additional  data  is  available  to  send,  a  radio  shall 
stop  transmitting  RF  power. 

Figure  27-12  provides  an  example  of  another  example  TxOp  timing  allocation.  This 
particular  example  shows  two  back-to-back  TxOp  allocations  for  the  same  source  radio.  A  radio 
is  not  required  to  shut  down  its  power  amplifier  if  its  next  allocated  TxOp  immediately  follows 
the  current  one. 
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Figure  27-12.  Example  TxOp  Timing  of  Two  Back-to-Back  TxOp 

Allocations 
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APPENDIX  27-A 
Air  Data  Rate  Model 

Calculations  leading  to  the  standardized  air  data  rate  for  the  RF  network  are  based  on 
three  spreadsheets.  These  spreadsheets  move  from  an  expected  distribution  of  data  use  at  the 
application  level  of  the  OSI  model  down  through  the  details  of  each  of  the  layers  leading  to  the 
physical  layer.  Descriptions  of  the  spreadsheets  are  provided  below.  While  the  path  concerning 
the  choices  made  is  not  directly  part  of  this  chapter,  the  spreadsheets  are  retained  due  to  their 
usefulness  in  explaining  the  overhead  and  transformations  that  occur  at  each  layer  of  the  overall 
stack. 


The  first  spreadsheet  contains  parameters  that  can  be  used  to  calculate  the  link  margin. 
The  spreadsheet  is  contained  here. 

The  second  spreadsheet  contains  equations  and  calculations  pertaining  to  the  RF  network. 
This  spreadsheet  is  contained  here.  The  spreadsheet  contains  two  tabs.  The  first  contains 
tunable  channel  parameters  that  are  used  to  calculate  bandwidth  estimates.  The  second  contains 
the  required  Eb/No  calculations.  Each  worksheet  is  described  below  in  more  detail. 

The  CH  Parameters  and  BW  Estimates  worksheet  contains  tunable  knobs  that  can  be 
modified  in  order  to  determine  the  impact  across  the  rest  of  the  RE  network.  The  most 
prominent  knobs  are  identified  by  dark  green  cells.  These  include  the  radio  air  channel  bit  rate 
(Rb),  the  number  of  TAs  in  the  RE  network  (Ntas),  the  minimum  latency  requirement  per  link, 
and  the  max  link  distance  to  be  accounted  for.  Eight-green  cells  are  also  knobs,  but  their  use  is 
expected  to  be  limited.  These  may  be  set  when  initializing  the  table.  This  includes  the  guard 
band  times  to  allocate  across  the  system  as  well  as  an  average  frame  length  of  network  traffic. 
Gray  cells  represent  constants  that  shall  not  be  modified.  They  correspond  to  parameters  such  as 
the  EDPC  coding  rate,  EDPC  codeblock  size,  EDPC  preamble,  ASM  sizes,  and  the  goal  rate  for 
mission  data  from  the  program.  The  light-pink  boxes  represent  calculated  values  based  on  the 
tuning  knobs. 

The  Req  EbNo  Values  worksheet  contains  error  rate  calculations  for  SOQPSK  modulation 
schemes.  These  include  bit  error  rates,  frame  error  rates,  packet  error  rates,  and  the  energy  per 
bit  to  noise  power  spectral  density  ratio  (Eb/No).  It  correlates  the  packet  error  rate  to  the  bit  error 
rate.  This  is  related  to  the  suggested  receiver  sensitivity  in  Subsection  27.3.3.1.3. 

The  final  spreadsheet  describes  the  data  rate  calculations  for  different  data  flows.  This 
spreadsheet  is  contained  here.  This  spreadsheet  contains  three  worksheets;  each  of  which 
describes  the  achievable  data  transfer  rate  for  a  particular  data  flow  based  on  the  effective  bit  rate 
provided  over  the  RE  channel.  Each  worksheet  contains  the  following  two  tuning  knobs. 

•  Rnt  network  throughput  (Mbps)  -  This  knob  allows  the  user  to  specify  the  total  bit  rate  of 
the  channel  for  IP  data.  This  data  rate  represents  the  maximum  data  rate  available  to 
IP  packets,  which  includes  data  payload  and  all  other  overhead  associated  with  the  IP 
packets. 

•  HAIPE  Setting  -  This  knob  specifies  the  block  truncation  setting  configuration  of  an 
inline  HAIPE  device.  This  knob  is  used  when  computing  the  associated  overhead  of 
a  particular  data  flow  for  cases  with  block  truncation  enabled. 
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When  the  Rnt  network  throughput  (Mbps)  knob  is  set  to  the  expected  IP  data  rate  over  the  RF 
channel,  the  Rmd  mission  data:  Application  Transfer  Rate  (Mbps)  columns  will  indicate  the 
theoretical  maximum  application  data  rate  across  the  system  for  the  types  of  data  specified.  This 
knob  can  also  be  tuned  in  order  to  set  the  Rmd  mission  data:  Application  Transfer  Rate  (Mbps)  to  a 
particular  value.  Once  the  desired  application  data  transfer  rate  is  reached,  the  knob  then 
indicates  the  IP  network  throughput  rate  that  would  be  required  in  order  to  achieve  the  calculated 
application  data  transfer  rate. 

The  three  worksheets  describe  typical  data  payload  and  associated  protocol  overhead 
bytes  for  the  different  types  of  data.  For  each  data  flow  in  each  worksheet,  the  overhead  bytes 
vary  depending  on  whether  block  truncation  is  enabled  or  not  at  the  encryptor.  Calculations  are 
performed  for  both  block  truncation  enabled  and  block  truncation  disabled.  For  each  case,  the 
percent  overhead  is  calculated  along  with  the  data  transfer  rate.  The  transfer  rate  is  a  function  of 
the  ratio  of  data  bytes  to  total  bytes  (data  plus  overhead)  times  the  effective  IP  bit  rate  available. 

A  list  of  assumptions  for  each  worksheet  is  provided.  The  data  flows  in  the  three 
worksheets  are  described  below. 

FTP  -  Reliability  Critical  -  TCP 

Transmission  Control  Protocol  (TCP)-based  data  flows,  such  as  file  transfer  protocol 
(FTP)  transfers  and  Reliability  Critical  data  retrieval  sessions,  attempt  to  maximize  payload 
sizes,  which  results  in  lowering  the  total  overhead  of  the  transport.  The  calculations  performed 
in  this  worksheet  assume  the  transfers  are  long  transfers  that  do  not  experience  any  connection/ 
disconnection  events.  It  also  assumes  the  typical  system  default  (e.g.,  un-optimized)  TCP 
parameters.  Other  assumptions  include  that  for  TCP-based  data  flows,  the  data  packets  fit  the 
block  truncation  size,  thus  not  requiring  any  additional  padding  bytes  when  block  truncation  is 
enabled  versus  when  block  truncation  is  disabled.  It  also  assumes  that  only  one 
acknowledgement  (ACK)  packet  is  returned  for  every  10  FTP  data  packets  sent. 

Overhead  bytes  include  FTP  overhead,  TCP  headers,  IP  headers,  and  all  HAIPE 
overhead.  Because  TCP  requires  ACKs  to  be  returned,  these  have  also  been  included  in  the  total 
overhead  calculation. 

Latency  Throughput  Critical  Data 

User  Datagram  Protocol-based  data  flows,  such  as  Latency  Throughput  Critical  data 
delivery  of  TmNSDataMessages,  come  in  a  variety  of  sizes.  These  different  sizes  affect  the 
percent  overhead  associated  with  each  flow.  If  the  data  flows  through  a  HAIPE  device  with  EPL 
enabled,  there  can  be  a  significant  impact  to  the  percent  overhead  and  realizable  application  data 
transfer  rate.  Because  of  this,  the  worksheet  provides  several  sizes  of  acquisition  data  in  order  to 
show  the  impacts  to  overhead  percentage  and  application  data  transfer  rates  between  ETP 
enabled  and  disabled  for  the  different  sizes  of  acquisition  data  payloads. 

SM 

System  Management  messages  assume  a  single  Simple  Network  Management  Protocol 
(SNMP)  request  receives  a  single  SNMP  response.  The  SNMP  protocol  data  unit  in  the  request 
is  considered  the  data  to  be  transferred  in  this  exchange.  The  entire  response  message  is 
considered  overhead  in  the  calculations. 
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CHAPTER  28 

RF  Network  Management 


28.1  Introduction 

This  chapter  defines  the  mechanisms  and  processes  for  managing  radio  frequency  (RF) 
links  with  the  RF  network.  The  RF  network  implements  an  Open  Systems  Interconnection  (OSI) 
model  approach  (Figure  28-1)  to  data  transmission,  where  data  moves  through  the  OSI  stack 
from  the  application  layer  to  the  physical  layer,  from  physical  layer  to  physical  layer  through 
some  transmission  medium,  then  back  up  the  stack  to  another  application  on  the  receiving  side. 
For  the  most  part,  the  RF  network  operates  just  like  any  other  Transmission  Control  Protocol 
(TCP)/Intemet  Protocol  (IP)  network,  where  a  message  is  created  using  a  standard  data 
management  protocol,  such  as  Simple  Network  Management  Protocol;  is  encapsulated  at  the 
transport  layer  to  TCP  or  User  Datagram  Protocol  (UDP);  and  then  is  further  encapsulated  into 
an  IP  packet  that  contains  the  logical  addressing  and  path  routing  determination.  Where  the  RF 
network  differs  from  the  standard  OSI  model  is  in  the  data  link  and  physical  layers,  where  media 
access  controls  (MACs)  have  been  modified  to  support  transmission  over  RF  links. 


OSI  Model 

Layer 

Data  Unit 

Function 

Examples 

Host 

Layers 

7.  Application 

Data 

High  Level  APIs,  including  resource  sharing,  remote  file 
access,  directory  services  and  virtual  terminals 

HTTP,  FTP,  SNMP,  SSH,  TELNET 

6.  Presentation 

Translation  of  data  between  a  networking  service  and 
an  application,  including  character  encoding,  data 
compression  and  encryption/decryption 

HTML,  CSS,  GIF 

5.  Session 

Managing  communications  sessions,  i.e.  continuous 
exchange  of  information  in  the  form  of  multiple  back- 
and-forth  transmissions  between  two  nodes 

RPC,  PAP,  SSL,  SQL 

4.  Transport 

Segments/Datagram 

Managing  communications  sessions,  i.e.  continuous 
exchange  of  information  in  the  form  of  multiple  back- 
and-forth  transmissions  between  two  nodes 

TCP,  UDP,  NETBEUI 

Media 

Layers 

3.  Network 

Packet 

Structuring  and  managing  a  multi-node  network, 
including  addressing,  routing  and  traffic  control 

IPv4  IPv6,  IPSec,  Apple  Talk,  ICMP 

2.  Data  Link 

Frame 

Reliable  transmission  of  data  frames  between  two 
nodes  connected  by  a  physical  layer 

PPP,  lEE  802.2  L2TP,  MAC,  LLDP 

Covered 
by  this 
chapter 

1.  Physical 

Bit 

Transmission  and  reception  of  raw  bit  streams  over  a 
physical  medium 

Ethernet  physical  layer,  DSL  USB,  ISDN,  DOCSIS 

IRIG  106 
Chapter  27 

Figure  28-1.  OSI  Model  as  Related  to  the  Telemetry  Network  Standard 

(TmNS)  RF  Network 


The  RF  network  manages  communications  at  the  data  link  and  physical  layers  of  the  OSI 
model.  This  chapter  focuses  on  the  RF  network  with  respect  to  managing  the  data  link  layer  of 
the  OSI  model.  The  RF  network  is  a  multi-node  network  with  a  network  layer  control  and  data 
plane.  The  control  plane  for  managing  the  RF  link  layer  multiple  access  is  described  in  this 
document.  For  information  on  the  physical  layer  of  the  RF  network,  refer  to  Chapter  27.  The 
RF  network’s  control  plane  uses  the  existing  ground  network  and  adds  RF  connectivity  to  allow 
changes  to  RF  transmission  and  capacity  allocation  in  transceivers  during  missions.  Radios  need 
not  establish  direct  bidirectional  links  with  other  transceivers  in  order  to  be  part  of  the  RF 
network.  Rather,  they  are  part  of  the  network  based  on  the  principles  and  standards  associated 
with  normal  IP  routing  protocols  and  need  only  support  one  or  more  paths  to  and  from  the 
overall  RF  network. 


28-1 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  28,  July  2017 


The  RF  network  media  access  utilizes  an  epoch- structure  transmission  scheme. 
Management  of  the  epoch  schedule  is  coordinated  through  the  interfaces  defined  in  this 
document. 

In  order  to  support  dynamic  updates  to  the  epoch  structure,  transceivers  update  their 
currently  active  policies  based  on  RF  network  messages.  These  messages  define  when  the 
transceiver  has  been  given  authority  to  transmit.  This  chapter  covers  the  setting  of  transmission 
opportunities  (TxOps)  and  the  associated  supporting  RF  network  messages,  which  are  defined  in 
Chapter  24.  The  end  product  of  the  link  layer  control  plane  messaging  is  the  coordinated 
definition  of  the  start  and  stop  times  associated  with  transmit  opportunities  in  the  RF  network. 

An  overview  of  the  RF  network’s  link  layer  concepts  is  given  in  Section  28.2. 

When  coordinating  the  transmission  of  multiple  transmitting  entities,  it  is  the 
responsibility  of  RF  link  management  to  sequence  the  sending  of  TxOp  messages  and  check  for 
feedback  of  assigned  TxOps  from  the  transmitting  entities  in  order  to  avoid  multiple  concurrent 
uses  of  the  channel  by  multiple  transmitters  as  required  by  range  policy.  The  TxOps  are 
assigned  with  either  a  finite  or  an  infinite  timeout  value.  An  example  of  an  epoch  structure  of  an 
RF  network  is  given  in  Section  28.3. 

A  specific  RF  link  manager  implementation  performing  the  RF  link  management 
function  and  the  transceivers  being  managed  are  all  RF  network  components  and  should  provide 
the  interfaces  covered  in  Chapters  22  through  25. 

The  bit  numbering,  bit  ordering,  and  byte  ordering  conventions  used  in  this  chapter  are 
described  in  Chapter  21  Appendix  21-B. 

28.2  RF  Network  Management  Concepts  and  Definitions 

28.2.1  Data  Link  Layer  Framing 

The  RF  network  provides  a  standards-based  IP  network  (Internet  Engineering  Task  Force 
[IETF]  Request  for  Comment  [RFC]  791  ^  and  RFC  2474^).  Eayers  supporting  this  IP  layer  are 
unique  to  the  TmNS  RF  network.  Figure  28-2  shows  an  overview  of  the  protocol  layers 
associated  with  sending  an  IP  packet  over  the  data  link  layer  and  RF  physical  interface.  The  IP 
packets  are  referred  to  as  MAC  service  data  units  (MSDUs)  and  are  comprised  of  complete  IP 
packets  containing  user  data.  The  MSDUs  are  placed  into  payload  blocks  with  aggregation  and 
fragmentation  performed  to  meet  the  maximum  transmission  unit  of  the  RF  channel.  Advanced 
Encryption  Standard  (AES)-Counter  with  Cipher  Block  Chaining  Message  Authentication  Code 
mode  Protocol  (CCMP)  encryption  may  be  used  to  provide  added  security  on  the  RF  link  by 
encrypting  the  payload  blocks.  The  length-limited  payload  blocks  are  separated  into  RF  MAC 
frames  and  link  layer  header  information  is  added.  Forward  error  correction  is  added  to  the  RF 
MAC  frames  to  create  EDPC  blocks  suitable  for  transmission  over  the  RF  interface.  Details  of 
the  lower  levels  of  this  protocol  are  covered  in  Chapter  27. 


'  Internet  Engineering  Task  Force.  “Internet  Protocol.”  RFC  791.  Updated  by  RFC  2474,  RFC  6864,  and  RFC 
1349.  September  1981.  Available  at  https://datatracker.ietf.org/doc/rfc791/. 

^  Internet  Engineering  Task  Force.  “Definition  of  the  Differentiated  Services  Field  (DS  Field)  in  the  IPv4  and  IPv6 
Headers.”  RFC  2474.  Updated  by  RFC  3260  and  RFC  3168.  December  1998.  Retrieved  18  April  2017.  Available 
at  https  ://datatracker.  ietf  org/doc/rfc2474/. 
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Figure  28-2.  Data  Link  Layer  Framing  Overview 


28.2.2  RF  Link  Management 

The  RF  link  management  is  responsible  for  scheduling  RF  transmissions  in  TmNS  radios. 
Time  synchronization  is  critical  to  the  orchestration  of  the  scheduling.  The  RF  link  management 
also  performs  route  selection  for  packets  transiting  from  the  wired  networks  to  the  RF  networks. 

There  is  at  least  one  RF  link  management  source  associated  with  a  ground  station.  The 
RF  link  management  on  the  range  may  be  controlling  one  or  more  transmitting  entities  on  the 
ground.  The  RF  link  management  also  controls  transmitting  entities  that  are  networked  through 
the  ground  network,  such  as  those  contained  on  test  articles. 

The  RF  link  management  provides  a  set  of  control  protocols  for  managing  a  transmitting 
entity’s  RF  spectrum  access.  These  protocols  include: 

•  Transmission  scheduling 

•  RF  transmission  capacity  management 

•  Handoff  management 

•  Power  management  -  TBD 

•  Link  and  RF  Traffic  Loading  Status 

28.2.3  Epoch  Structure 

The  RF  network  implements  an  epoch  structure  to  provide  an  efficient  utilization  over  a 
shared  bandwidth.  Link  management  messages  support  dynamic  adjustment  of  the  epoch 
structure  being  utilized  by  components  comprising  an  RF  network. 

28.2.4  Transmission  Opportunities 

A  TxOp  is  a  window  in  time  over  which  a  transmitting  entity  may  transmit  over  its 
associated  RF  interface.  The  TxOp  contains  a  start  time  and  stop  time  that  is  relative  to  a 
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repeating  time  boundary  that  is  referred  to  as  an  epoch.  The  epoch  is  settable  to  a  number  of 
discrete  times  during  initialization. 


28.2.5  Guard  Time 

Guard  time  is  the  time  utilized  by  an  overall  RF  network  epoch  schedule  to  assure  clock 
jitter  and  RF  propagation  delays  do  not  create  undesired  RF  collisions.  There  are  no  RF  network 
messages  associated  that  specify  guard  time.  Rather,  the  TxOps  that  are  allocated  to  components 
within  an  RF  network  should  be  set  up  in  a  fashion  in  order  to  support  the  desired  guard  time. 
Chapter  23  specifies  an  interface  for  communicating  guard  time  to  an  RF  link  manager 
component.  Default  guard  time  is  recommended  to  be  1  millisecond. 

28.2.6  Traffic  Engineering  Queues 

The  RF  network  components  that  are  intended  to  behave  as  IETF  IP  routers  shall  provide 
Quality  of  Service  (QoS)  handling  of  traffic  that  is  delivered  to  the  RF  interface.  The  QoS 
interface  is  implemented  in  the  form  of  Traffic  Engineering  (TE)  queues.  As  such,  the  behavior 
concerning  the  ingress  and  subsequent  egress  (or  in  overload  situations,  drop)  of  messages  shall 
comply  with  the  details  specified  in  Chapter  22. 


28.2.7  Handoff 


Handoff  is  a  process  by  which  the  RE  path  is  changed  to  use  a  different  RE  network 
interface.  In  this  way,  the  route  (path)  of  RE  propagation  that  is  experiencing  undesired  receive 
RE  quality  can  be  directed  to  a  different  path.  This  updated  path  (post-handoff)  will  be  through  a 
different  RE  network  interface  that  may  be  in  the  current  RE  network  or  it  may  include  switching 
to  another  RE  network.  This  chapter  does  not  provide  a  particular  mechanism  for  performing 
handoff  operations  but  rather  a  sequence  of  use  of  RE  management  interfaces  that  can 
accomplish  a  variety  of  handoff  operations. 


NOTE 


r 


It  is  expected  that  handoff  will  be  performed  when  a  test  article  transceiver  begins 
to  move  out  of  range  of  a  ground  antenna,  moves  from  one  RE  network  to  another, 
or  moves  from  one  range  to  another.  This  chapter  does  not  specify  a  policy  for 
when  a  handoff  is  to  be  performed.  It  can  be  automatically  or  manually  directed. 


28.2.8  Heartbeat 

The  Heartbeat  mechanism  defines  a  relative  time  to  automatically  cease  transmissions 
and  clear  all  TxOps  from  the  transmission  schedule  for  a  transmitting  entity.  The  initial 
heartbeat  value  shall  be  loaded  from  a  Metadata  Description  Eanguage  (MDE)  configuration  file, 
and  the  value  shall  be  updated  upon  reception  of  an  RE  network  message  containing  a  Heartbeat 
Type  Eength  Value  (TEV).  Reception  of  an  RE  network  message  containing  a  Heartbeat  TEV 
from  RE  link  management  that  is  directed  to  any  RE  network  interface  on  the  receiving 
transmitting  entity  will  refresh  the  heartbeat  counter  for  all  RE  network  interfaces  (e.g.,  links)  on 
which  the  transmitting  entity  is  processing  TxOps.  Einks  are  defined  in  Subsection  28.2.10. 


28-4 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  28,  July  2017 


28.2.9  RF  MAC  Header  Addressing 

An  RF  MAC  address  source/destination  pair  that  defines  the  endpoint  of  an  RF 
transmission  is  called  a  “link”.  Links  are  individually  managed,  including  scheduled,  by  the  RF 
link  management. 

The  RF  MAC  address  shall  be  a  16-bit  value  subdivided  into  a  Vendor  ID  field  (most 
significant  4  bits)  and  an  RF  Interface  field  (least  significant  12  bits),  whereby  the  Vendor  ID 
field  uniquely  identifies  the  manufacturer  and  the  RF  Interface  field  further  uniquely  identifies 
an  RF  component  produced  by  that  manufacturer.  One  of  the  Vendor  ID  fields  is  reserved  for 
RF  multicast  group  addresses.  Table  28-1  displays  RF  MAC  header  vendor  IDs. 


Table  28-1.  RF  MAC  Header  Vendor  IDs 

Vendor  IDs 

Description 

4’bOOOO 

Reserved 

4’b0001-4’bll01 

Vendors 

4’blllO 

Experimental 

4’bllll 

Multicast 

The  assignment  of  a  unique  Vendor  ID  value  to  each  manufacturer  is  outside  the  scope  of 
this  chapter.  Manufacturers  are  responsible  for  ensuring  the  uniqueness  of  the  RF  MAC  address 
space  of  the  components  they  produce. 

28.2.10  Timing 

The  RF  link  management  and  all  entities  under  its  control  shall  have  their  clocks 
synchronized.  Methods  of  time  synchronization  are  defined  in  Chapter  22.  The  format  of  the 
time  in  RF  network  messages  is  defined  in  Chapter  24. 


28.2.11  Virtual  TxOps 


When  a  transmitting  entity  does  not  have  any  TxOps  allocated  for  the  current  or  any 
future  epochs,  a  Virtual  TxOp  time  slot  shall  be  available  for  responding  to  link  layer  control 
plane  TCP  connection  over  the  RF  interface.  The  Virtual  TxOp  shall  be  a  single  burst  in  size 
and  shall  be  located  at  the  beginning  of  each  Global  Positioning  System  (GPS)  second.  This 
allows  the  RF  link  management  to  receive  return  messages  from  a  transmitting  entity  in  the 
exchange  of  TCP  control  messaging  after  which  time  a  TxOp  Assignment  TLV  can  be  sent  to  the 
transmitting  entity  in  order  to  maintain  long-term  communications. 


NOTE 


y 


The  RF  link  management  uses  a  TCP  connection  that  requires  a  bidirectional 
handshake  to  occur  before  TxOp  Assignment  TLVs  can  be  received.  The 
use  of  the  Virtual  TxOp  transmission  allows  standard  TCP  methods  to 
establish  the  link  layer  control  path  without  using  unprotected  messaging. 


28.2.12  Independent  Operation 

An  RF  network  shall  be  capable  of  operating  independent  of  RF  link  management 
control.  In  this  mode  of  operation,  TxOp  allocations  are  the  result  of  configuring  with  an  MDL 
file  that  contains  the  transmission  schedule.  A  heartbeat  value  of  infinite  allows  TxOp 
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assignments  to  remain  in  effect  indefinitely,  assuming  the  TxOp  timeout  value  remains  greater 
than  zero,  or  until  RF  link  management  changes  the  value  by  sending  a  non-infinite  heartbeat 
value  in  a  Heartbeat  TLV.  The  transmitting  entity  operating  independent  of  RF  link 
management  as  described  shall  allow  RF  link  management  control  to  take  over  independent 
operations.  An  independent  transmitting  entity  allows  externally  received  Heartbeat  TLVs  and 
TxOp  Assignment  TLVs  to  overwrite  MDL-provided  values. 

28.3  RF  Media  Access  Control  Layer 

The  RF  MAC  layer  is  responsible  for  providing  access  to  the  physical  media  (i.e.,  the 
wireless  RF  network).  On  the  transmission  side,  it  is  responsible  for  framing  IP  packets  for 
physical  transmission  (adding  in  the  layer  2  hardware  addresses  for  the  source/destination  pair  of 
the  link).  On  the  receive  side,  it  is  responsible  for  validating  the  checksum  sent  with  each  packet 
(known  as  the  frame  check  sequence  [FCS])  and  de-framing  the  received  packet. 

28.3.1  Epoch 

The  RF  channel  will  be  supported  by  an  epoch  structure  to  separate  transmission  signals. 
It  emulates  full-duplex  communication  over  a  half-duplex  link  and  is  utilized  by  the  TmNS  RF 
network.  The  transmitting  entity  shall  synchronize  the  epoch  start  time  with  a  commonly 
referenced  external  time  synchronization  mechanism  that  is  common  to  the  RF  network. 

28.3.1.1  Epoch  Structure 

An  epoch  structure  shall  contain  an  integer  multiple  of  TxOp  assignments.  The  number 
of  TxOps  and  their  durations  are  assigned  according  to  the  need  and  policy  that  has  been  put  in 
place  by  RF  link  management.  Figure  28-3  depicts  an  example  of  a  schedule  with  four 
transmitting  entities  in  a  network  with  TxOps  to  access  the  RF  network. 


Unscheduled  Time  Unscheduled  Time 


Figure  28-3.  Typical  Epoch  Structure 


Transmitting  entities  in  the  network  are  only  aware  of  the  start  and  stop  times  of  a  TxOp, 
and  it  is  the  responsibility  of  RF  link  management  to  provide  unscheduled  time  in  order  to 
provide  sufficient  guard  times  when  scheduling  TxOps.  For  times  other  than  the  assigned  TxOp 
periods  in  an  epoch,  a  transceiver  shall  transition  to  receive  mode,  i.e.,  capable  of  receiving 
transmissions  destined  for  it.  When  there  are  no  packets  ready  to  be  transmitted  when  a 
scheduled  TxOp  period  occurs,  the  transmitting  entity  shall  not  transmit.  A  detailed  description 
of  the  TmNS  RF  burst  sequence  requirements  for  the  transmitting  entity  can  be  found  in  Chapter 
27. 
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28.3.1.2  Epoch  Timing 

The  duration  of  the  epoch  frame  period  shall  be  constrained  to  the  following  allowable 
values:  1000  ms  (maximum  epoch  size),  500  ms,  250  ms,  125  ms,  100  ms  (default  epoch  size), 
50  ms,  40  ms,  25  ms,  20  ms,  10  ms  (minimum  epoch  size).  Epoch  size  for  a  transmitting  entity 
shall  only  be  set  during  configuration  through  the  MDE  configuration  file.  It  is  not  required  that 
RE  link  management  update  the  allocated  capacity  at  the  same  rate  as  the  epoch  period  used  in 
the  RE  network.  Epochs  shall  be  aligned  with  time-synchronized  seconds  as  defined  in  Chapter 
22  corresponding  with  a  transition  between  two  adjacent  epochs. 


While  this  chapter  allows  for  different  components  within  an  RE 
network  to  be  configured  with  different  epochs,  it  is  expected  that 
all  epochs  will  be  the  same. 


NOTE 


28.3.1.3  Guard  Times 

Between  TxOp  allocations,  a  period  of  no  transmissions  referred  to  as  a  guard  time  may 
be  provided  by  RE  link  management  or  independent  MDE  configuration  to  allocate  time  between 
transmissions.  Guard  times  also  can  be  used  to  account  for  RE  propagation  delays  across  the 
range.  It  is  the  responsibility  of  the  RE  link  management  to  provide  guard  times  between  the 
TxOps  that  it  allocates.  Guard  times  are  intentional  gaps  in  the  epoch  structure  in  which  no 
transmitting  entity  has  a  TxOp. 

28.3.1.4  Transmission  Opportunity 

The  use  of  TxOps  provides  a  mechanism  of  provisioning  coordinated  channel  capacity 
across  multiple  transmitting  entities  on  an  RE  network  based  on  the  policies  in  place  for  the 
range.  To  access  the  RE  media,  one  or  more  TxOps  is  assigned  to  a  transmitting  entity.  A  single 
TxOp  is  the  authority  of  the  transmitting  entity  to  transmit  to  its  RE  interface  between  two  time 
periods,  referred  to  as  start  and  stop  times.  The  start  and  stop  times  of  a  TxOp  are  defined 
relative  to  a  recurring  epoch  start  time.  The  epoch  start  time  of  a  transmitting  entity  should  be 
synchronized  with  GPS  seconds  or  external  time  synchronization  as  defined  in  Chapter  22. 

Each  TxOp  has  a  defined  destination  RE  MAC  address  (e.g.,  link)  that  is  set  to  the  RE 
MAC  address  of  an  individual  transceiver  or  an  RE  multicast  group  address.  Transceivers  can  be 
set  to  listen  on  one  or  more  multicast  addresses  in  addition  to  their  RE  MAC  address.  Multiple 
TxOps  can  be  assigned  to  a  transmitting  entity  that  are  for  the  same,  different,  or  a  combination 
of  RE  MAC  addressed  destinations. 

If  a  transmitting  entity  does  not  have  sufficient  data  to  generate  burst  sequences  that 
completely  fill  a  TxOp,  then  it  may  cease  transmission  after  all  needed  burst  sequences  have 
been  transmitted,  i.e.,  a  transmitting  entity  is  not  required  to  pad  to  fill  a  TxOp. 

If  a  transmitting  entity  has  ceased  transmission  in  a  TxOp  and  more  data  becomes 
available  to  be  transmitted  while  there  is  sufficient  time  remaining  in  the  TxOp  both  to  allow  the 
minimum  time  between  transmissions  and  to  transmit  one  or  more  complete  burst  sequences, 
then  the  transmitting  entity  shall  resume  transmission,  transmitting  one  or  more  contiguous  burst 
sequences. 
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NOTE 


The  timeout  value  in  the  TxOp  TLVs  allows  epochs  of  transmissions  and  not 
each  transmission  to  be  scheduled.  This  relaxes  the  requirement  of  RF  link 
management  processing  and  supporting  network  speed.  Prior  to  the  addition 
of  the  timeout  functionality,  the  RF  link  management  was  required  to 
generate  the  complete  network  complement  of  RF  network  messages 
containing  TxOp  TLVs  and  transfer  them  to  the  transmitting  entities, 
meeting  tight  setup  times,  each  epoch  for  proper  RF  data  plane  management. 


28.3.2  Media  Access  Control  Frame  Structure 

The  MAC  frame  structure  determines  what  RF  transmissions  are  received.  The  RF  MAC 
filters  received  traffic,  accepting  only  those  RF  transmissions  that  the  receiving  entity  is 
interested  in  receiving. 

28.3.2.1  Header  Format 

Frame  headers  for  RF  MAC  control  frames  contain  the  destination,  source,  and  a  length. 
The  destination  address  is  either  an  RF  MAC  address  of  the  destination  transceiver  or  an  RF 
multicast  address  that  specifies  the  RF  multicast  group  that  receiving  entities  can  listen  to.  The 
source  address  is  always  the  RF  MAC  address  of  the  transmitting  entity.  A  length  is  included 
that  indicates  the  length  of  the  MAC  payload  in  the  MAC  frame.  Additional  information  about 
the  RF  MAC  frame  format  can  be  found  in  Chapter  27. 

28.3.2.2  Unprotected  Payload 

All  link  layer  control  frames  are  contained  in  secure  TCP  payload  streams  with  only  the 
RF  MAC  layer  header  including  the  source  and  destination  sent  unprotected.  The  FCS  is  also 
sent  unprotected  to  allow  for  physical  layer  verification  of  a  correctly  received  frame. 

28.3.2.3  Protected  Payload 

The  link  layer  control  frames  are  contained  in  TCP  secure  IP  packets.  These  frames 
contain  RF  network  messages  to  control  transmissions  on  the  RF  network.  If  AES  encryption  is 
used,  then  the  secure  TCP  packets  will  have  an  additional  level  of  encryption. 

28.3.3  RF  MAC  Payloads 

The  MSDUs  are  received  from  upper  protocol  layers  by  the  RF  link  layer  and  are 
aggregated,  fragmented,  or  directly  placed  into  payload  blocks.  The  payload  blocks  have  a 
fragmentation/packing  sub-header  (FPSH)  header  added  to  preserve  the  original  MSDU  shape 
when  reconstruction  is  performed  at  the  link  layer  on  the  receiving  end.  The  combined  payload 
block  and  FPSH  header  are  then  encapsulated  either  encrypted  or  unencrypted  into  the  RF  MAC 
frame  described  in  Chapter  27.  This  is  shown  in  Figure  28-4. 
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Figure  28-4.  MSDU  Insertion  into  RF  MAC  Frame 


28.3.3.1  RF  MAC  Service  Data  Units 

The  RF  MAC  service  data  units  (MSDUs)  are  portions  of  messages  to  be  transmitted 
across  the  RF  link.  The  MSDUs  are  placed  into  blocks  with  aggregation  and  fragmentation 
performed. 

28.3.3.2  RF  MAC  Frame  Fragmentation 

If  an  IP  packet  is  too  long  to  fit  into  an  RF  MAC  frame,  then  it  is  fragmented,  which  is 
the  process  by  which  an  RF  MSDU  is  divided  into  one  or  more  MSDU_B locks.  An 
MSDU_Block  contains  a  full  MSDU  or  a  fragment  of  an  MSDU.  The  fragmentation  process  is 
undertaken  to  allow  efficient  use  of  available  payload  in  an  RF  MAC  frame.  Capabilities  of 
fragmentation  and  reassembly  are  required.  Fragments  are  tagged  with  their  position  in  their 
parent  SDU  in  accordance  with  the  values  defined  for  the  Fragmentation  Control  field  shown  in 
Table  28-2. 


Table  28-2.  Definition  of  Fields  in  Fragmentation/Packing  Sub -Header 

Field 

Width 

(Bits) 

Description 

FC 

2 

Fragmentation  Control 

Indicates  the  fragmentation  state  of  the  payload  MSDU: 

00  =  no  fragmentation 

01  =  last  fragment 

10  =  first  fragment 

11  =  continuing  (middle)  fragment 

Reserved 

3 

Reserved 

BSN 

11 

Block  sequence  number  (BSN)  for  this  MSDU_Block 
[0  ...  2047]  modulo  2048 
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Priority 

3 

Priority  ranking  for  this  MSDU Block 

Eength 

13 

Eength  (in  bytes)  of  this  MSDU_Block,  including  this  six -byte  EPSH  [7 
...  500] 

Protocol 

16 

Type  of  Protocol 

Use  standard  Ethernet  values 

TOTAE 

48 

Multiple  short  RF  MSDUs  and/or  fragments  of  RF  MSDUs  can  be  packed  in  the  same 
RF  MAC  frame.  Capabilities  of  packing  and  unpacking  are  required.  When  an  RF  MSDU  is  not 
fragmented,  the  Fragmentation  Control  field  in  the  FPSH  shall  be  set  to  00  (“No 
Fragmentation”) . 


An  FPSH  precedes  each  fragment  or  packed  entity.  Each  fragment  or  packed  message  is 
itself  an  MSDU_Block.  The  FPSH  structure  is  depicted  in  Figure  28-5. 


-♦ 


1 6  bits 


Tj- 


CD 


00 


C£) 


CO 


FC 

(2  bits) 

Reserved 
(3  bits) 

Block  Sequence  Number  (BSN) 

(1 1  bits) 

Priority 
(3  bits) 

Length  ofthe  MSDU  or  fragment 
(13  bits) 

Type  of  Protocol 
(16  bits) 

Figure  28-5.  Fragmentation/Packing  Sub-Header 


The  MSDU_Block  size  shall  be  variable  with  a  maximum  of  494  bytes  in  an  unprotected 
RF  MAC  frame  and  478  bytes  in  an  RF  MAC  frame  protected  with  AES-CCMP  encryption. 

The  link  layer  control  messages  described  in  this  document  are  sent  within  standard  IP 
packets  that  are  marked  as  IP  type  in  the  Protocol  field. 

If  an  RE  MAC  frame  has  a  payload  field,  the  payload  shall  comprise  one  or  more 
MSDU_Blocks  each  with  its  associated  EPSH.  See  the  notional  diagram  in  Eigure  28-6. 
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Figure  28-6.  Notional  Diagram  of  RF  MAC  Frame  Containing  Two 

MSDU_Blocks 


Whenever  possible,  the  payload  of  an  RF  MAC  frame  shall  be  completely  filled.  This 
may  necessitate  fragmenting  the  next  MSDU  that  is  to  be  transmitted. 

If  there  are  6  bytes  or  fewer  remaining  in  a  payload,  the  remaining  bytes  shall  be  padded 
with  zeroes.  The  length  field  in  each  FPSH  tells  the  size  of  the  following  MSDU_Block. 

If  an  MSDU  is  fragmented  into  multiple  MSDU_Blocks,  the  multiple  MSDU_Blocks 
shall  be  transmitted  in  the  same  order  in  which  they  occurred  in  the  MSDU  and  shall  have  BSNs 
that  are  consecutive  integers,  modulo  the  BSN  modulus. 

If  an  MSDU  is  fragmented  into  multiple  MSDU_B locks  and  all  the  MSDU_Blocks  are 
not  transmitted  in  a  single  TxOp,  then  the  remaining  MSDU_Blocks  should  be  the  first  new 
MSDU_Blocks  sent  at  this  priority  level.  When  MSDU_Blocks  are  available  for  more  than  one 
priority  level,  MSDU_Blocks  marked  with  the  higher  numeric  priority  values  shall  be  chosen 
over  lower  numeric  priority  values. 

28.3.4  Frame  Check  Sequence 

The  FCS  contained  at  the  end  of  an  RF  MAC  frame  shall  serve  as  a  link  layer  error¬ 
checking  mechanism.  The  FCS  generation  and  verification  is  covered  in  Chapter  27. 
Additionally,  the  higher-layer  protocols  (e.g.,  IP  checksums)  perform  their  own  error  checking. 


28.4  Logical  Link  Control  Layer 

The  logical  link  control  (LLC)  layer  of  the  RF  network  provides  media  access  control  and 
transfer  of  data  frames.  The  LLC  layer  provides  the  control  mechanisms  for  dynamically 
managing  transmission  bandwidth. 


Epoch-based  RF  link  management  is  accomplished  by  sending  RF  network  messages  to 
the  transmitting  entities  to  modify  the  current  transmission  schedules. 


NOTE 


All  RF  link  management  messages  are  sent  using  a  secure  TCP 
connection  with  the  transmitting  entity.  Details  of  secure 
connections  are  provided  in  Chapter  22  Subsection  22.4.3. 
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The  RF  network  messages  are  sent  with  IP  Precedence  as  defined  in  Chapter  22 
Subsection  22.5.3.2. 

An  RF  network  message  may  contain  multiple  types  of  TLVs.  When  an  RF  network 
message  contains  multiple  TLVs,  each  TLV  shall  be  processed  in  the  order  in  which  they  are 
packed. 

28.4.1  TxOp  Processing 

The  external  loading  of  a  schedule  of  TxOps  from  external  MDL  shall  be  equivalent  to 
receiving  a  sequence  of  RF  network  messages  with  TxOp  Assignment  TLVs.  An  export  of  a 
transmitting  entity’s  configuration  in  MDL  shall  include  all  the  currently  scheduled  TxOps 
regardless  of  whether  they  originate  from  TxOp  Assignment  TLVs  in  RF  network  messages,  an 
MDL  configuration  file,  or  a  combination  of  both  input  sources.  The  transmitting  entity  shall 
allow  TxOp  Assignment  TLVs  received  in  RF  network  messages  to  modify  existing  scheduled 
TxOps,  including  those  initially  set  during  configuration  with  an  MDL  file. 

A  TxOp  assignment  for  a  transmitting  entity  may  be  different  in  each  epoch,  and  multiple 
TxOp  Assignment  TLVs  for  use  in  a  single  epoch  may  be  sent  in  the  same  RF  network  message 
from  RF  link  management.  Received  TxOps  shall  take  effect  within  two  complete  epoch  start 
times  after  reception.  For  each  allocated  TxOp  in  a  transmitting  entity’s  schedule,  the 
transmitting  entity  shall  send  a  status  RF  network  message  containing  TLVs  with  both 
information  on  all  QoS  transmit  queue  levels  and  receiver  link  quality  to  RF  link  management. 

An  RF  network  message  containing  one  or  more  TxOp  Assignment  TLVs  can  be  sent  by 
RF  link  management  and  likewise  be  received  at  any  time  during  the  epoch  by  a  transceiver. 
TxOp  Assignment  TLV  adjustments  are  state-based,  that  is  they  adjust  the  epoch  schedule  based 
on  top  of  all  prior  adjustments  that  were  accomplished.  A  TxOp  Assignment  TLV  can  add, 
remove,  or  modify  an  existing  TxOp  window  for  transmissions.  A  modification  of  a  currently 
active  TxOp  Assignment  TLV  occurs  when  a  new  TxOp  Assignment  TLV  completely  subsumes 
an  existing  TxOp.  The  start  time  of  the  new  subsuming  TxOp  should  be  equal  to  or  earlier  than 
the  existing  TxOp  and  the  stop  time  should  be  equal  to  or  greater  than  the  existing  TxOp. 

The  TxOp  Assignment  TLV  also  contains  a  timeout  value  that  specifies  the  lifetime  of 
the  TxOp  as  measured  in  epochs.  The  timeout  value  can  be  zero,  which  will  result  in  the 
removal  of  one  or  more  TxOps  that  are  completely  subsumed  by  the  TxOp  Assignment  TLV 
received  regardless  of  their  former  timeout  values.  If  the  timeout  value  is  infinity,  which  is 
defined  as  the  value  255,  the  TxOp  defined  by  the  received  TLV  is  put  in  place  with  no  epoch- 
based  timeout,  and  it  shall  replace  all  TxOps  that  are  subsumed  by  the  start  and  stop  times  of  the 
TxOp  TLV. 

The  TxOp  Assignment  TLVs  are  associated  with  a  particular  RF  link  that  is  a  source  and 
destination  pair  of  RF  MAC  addresses  that  identifies  the  source,  e.g.,  the  radio  that  is  to  use  the 
particular  TxOp,  and  the  destination  RF  MAC  address  to  which  it  is  to  transmit.  Any 
transmitting  entity  that  transmits  to  multiple  destination  groups  shall  have  separate  TxOp 
Assignment  TLVs  sent  to  it  in  order  to  differentiate  which  RF  interface  is  being  allocated  for 
transmission.  The  associated  link  is  contained  in  the  RF  network  message  header. 

Each  time  the  transmission  schedule  of  a  transmitting  entity  is  updated,  it  shall  report  to 
RF  link  management  with  an  RF  network  message  containing  a  TxOp  ID  Acknowledgement 
Report  TLV.  The  report  shall  be  generated  after  the  new  schedule  has  been  applied.  The  report 
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may  be  generated  in  the  epoch  prior  to  the  first  use  of  the  associated  TxOp  if  the  relative  start 
time  and  stop  time  have  already  occurred  within  the  current  epoch  if  the  new  TxOp  will  be  first 
utilized  during  the  next  epoch.  The  TxOps  with  ID  values  of  zero  (16’hOOOO)  shall  not  be 
acknowledged  by  transmission  entities.  The  TxOp  ID  Acknowledgement  Report  TLVs  are  not 
specific  to  the  particular  source  and  destination  RF  MAC  addresses  contained  in  the  message 
header  of  the  RF  network  message  containing  the  TLV.  If  the  RF  network  message  only 
contains  the  TxOp  ID  Acknowledgement  Report  TLV,  then  the  RF  network  message  header 
should  use  its  own  RF  MAC  address  as  the  source  address  and  a  valid  RF  MAC  address  for  the 
destination  address,  such  as  the  address  pair  associated  with  the  RF  network  messages  that 
contain  the  TxOp  Assignment  TLV  messages  from  RF  link  management. 

A  transmitting  entity  may  only  transmit  over  a  particular  RF  interface  at  the  frequency 
and  for  the  epoch-based  periodic  time  slot  that  has  been  specified  in  a  valid  TxOp  Assignment 
TLV.  Any  time  a  TxOp  is  executed,  the  frequency  of  the  transceiver  is  set  according  to  the 
associated  frequency  value  that  was  specified  in  the  corresponding  TxOp  Assignment  TLV,  and 
transmission  is  allowed  for  the  duration  of  the  TxOp.  If  a  TxOp  Assignment  TLV’s  start  time  is 
equal  to  its  stop  time  (i.e.,  time  duration  is  zero),  it  shall  be  considered  a  valid  TxOp  Assignment 
TLV. 


NOTE 


A  zero-duration  TxOp  may  be  used  to  support  handoff  scenarios  that 
involve  a  frequency  change.  That  is,  they  provide  a  mechanism  that 
supports  commanding  a  transceiver  to  change  its  receiving  frequency 
but  does  not  give  authority  to  transmit  over  the  new  frequency. 
Rather,  a  TxOp  received  on  the  new  frequency  from  a  different  RF 
network  management  entity  would  then  give  authority  to  transmit. 


Each  TxOp  is  given  a  lifetime  in  terms  of  the  number  of  epochs  that  it  is  valid  for.  The 
lifetime  may  be  updated  before  it  expires  on  its  own  if  a  new  TxOp  Assignment  TLV  arrives 
with  a  start  and  stop  time  that  completely  subsumes  an  existing  scheduled  TxOp. 

Multiple  TxOp  Assignment  TLVs  may  be  packed  into  a  single  RF  network  message  if  the 
associated  TxOps  are  destined  for  the  same  source  over  the  same  RF  interface  (link). 

Because  start  and  stop  times  are  relative  to  the  size  of  the  epoch,  a  time  window  equal  to 
the  size  of  the  epoch  is  used  to  define  when  the  start  time  and  stop  time  in  a  TxOp  Assignment 
TLV  are  considered  to  be  valid.  The  TxOp  Assignment  TLVs  that  define  TxOps  falling  outside 
this  window  shall  be  discarded. 

Because  the  start  and  stop  times  of  TxOps  are  quantized  values  (limited  to  integers  that 
represent  microseconds  within  an  epoch),  the  start  time  shall  correspond  to  times  greater  than  or 
equal  to  the  time  represented  by  the  value  of  the  start  time  field.  The  stop  time  shall  correspond 
to  the  exact  instance  of  the  greatest  value  that  is  less  than  the  stop  time  field  plus  1.  Thus,  the 
valid  transmission  time  associated  with  a  TxOp  shall  be  according  to  the  following  equation: 

^start  ^  valid  transmission  range  <  tgf-op  +  1 

If  the  start  time  of  one  TxOp  is  equal  to  the  stop  time  -i-  1  of  the  previous  TxOp,  the 
TxOps  can  be  called  back-to-back  TxOps.  From  a  transmitter’s  perspective,  back-to-back 


28-13 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  28,  July  2017 


TxOps  allow  continual  transmission  without  a  requirement  to  turn  off  the  transmitter  power  prior 
to  the  conclusion  of  the  first  TxOp. 

From  a  transmitting  entity’s  perspective  of  the  system,  each  time  an  epoch  is  processed, 
all  scheduled  TxOps  that  contain  a  non-zero  timeout  value  will  be  executed.  After  execution,  the 
timeout  value  associated  with  that  TxOp  will  be  decremented  by  one  unless  it  is  an  infinite  TxOp 
with  a  timeout  value  of  255.  Once  the  timeout  value  of  a  TxOp  reaches  the  value  of  zero,  it  is 
removed  from  any  future  processing.  For  infinite  TxOps,  the  timeout  does  not  decrement  after 
execution. 


28.4.1.1  TxOp  Processing  After  Power  Interruption 


In  the  event  of  power  interruption,  the  transceiver  shall  configure  itself  to  receive  using 
the  relevant  parameters  of  the  last  processed  TxOp  or  the  configuration  data  from  the  last  loaded 
MDL  configuration  file,  whichever  occurred  more  recently.  If  no  valid  TxOps  exist,  it  shall  be 
assumed  that  no  transmission  slots  are  allocated  to  it  for  the  next  epoch.  The  transceiver  shall 
continue  to  perform  its  receiver  functionality. 


NOTE 


In  the  event  of  a  power  interruption,  the  transceiver  should  store  its  current 
TxOps  and  associated  timeout  values.  After  booting  back  up,  the  transceiver 
shall  resume  transmissions  if  the  TxOps  have  not  timed  out  and  the  transceiver’s 
heartbeat  timeout  is  not  zero.  This  can  be  determined  by  calculating  the  number 
of  epochs  that  have  passed  since  the  reboot  event.  The  transceiver  should  still 
obtain  time  synchronization  prior  to  executing  any  TxOps. 


28.4. 1 .2  TxOp  Processing  When  Heartbeat  Times  Out 

If  the  timeout  value  for  the  last  received  heartbeat  from  RF  link  management  expires 
before  the  receipt  of  the  next  heartbeat,  the  transceiver  shall  flush  all  scheduled  TxOps  with  a 
remaining  non-zero  timeout  value  that  was  received. 

Any  new  TxOp  Assignment  TLVs  that  are  received  whose  current  heartbeat  timeout 
value  is  zero  shall  be  discarded.  A  non-zero  heartbeat  timeout  is  required  in  order  to  process 
new  TxOp  Assignment  TLVs. 

See  Subsection  28.4.4  for  more  information  regarding  Heartbeat  TLVs. 

28.4.2  Queue  Management  Processing 

A  MAC  Queue  Status  Report  TLV  in  an  RF  network  message  shall  be  generated  to 
provide  the  state  of  traffic  loading  in  the  TE  queue  interface  to  the  RF  channel  as  defined  in  this 
chapter  as  well  as  Chapter  22,  Chapter  23,  and  Chapter  27.  The  MAC  Queue  Status  Report 
TLVs  shall  contain  traffic  loading  for  each  DiffServ  Code  Point  type  contained  in  the 
transmitting  entity.  The  traffic  loading  shall  include  all  storage  in  traffic  bearers  contained 
within  the  transmitting  entity.  This  RF  network  message  is  generated  once  per  TxOp  and  occurs 
at  the  start  of  each  burst.  These  chapters  specify  that  there  are  eight  TE  queues,  each  of  which 
corresponds  to  a  specific  lETE  Precedence  Class  as  summarized  by  the  table  contained  in 
Chapter  22.  Chapter  23  defines  the  TE  queue  to  lETE  class  mapping  and  also  includes  details  of 
the  MDE  grammar  that  provides  a  method  to  define  user-specific  per  hop  behaviors  for  a  mission 
and  how  they  apply  to  each  of  the  TE  queues  (Precedence  Classes).  Transmitting  entities  shall 
comply  with  the  QoS  concepts  defined  in  this  chapter.  Chapter  22,  Chapter  23,  and  Chapter  27 
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by  selecting  MSDUs  to  send  when  a  TxOp  occurs  based  on  the  overall  policy  that  has  been 
specified  through  MDL.  This  selection  process  is  therefore  the  overall  configured  policy  for  the 
mission  and  specifies  the  behavior  choice  process  that  is  to  be  used  across  the  TE  queues.  As 
long  as  time  within  the  TxOp  remains,  further  messages  shall  be  sent  based  on  the  TE  queue 
policies  until  the  TxOp  is  over. 


It  is  expected  that  typical  RE  link  management  uses  a  combination 
of  instantaneous  historical  queue  status  TEVs  to  determine 
potential  adjustment  to  link  layer  TxOp  allocations. 


NOTE 


28.4.3  Eink  Metric  Processing 

The  Eink  Metric  TEV  is  used  to  inform  RE  link  management  of  the  quality  of  the 
received  data  signal  in  the  transceiver.  Once  a  TCP  connection  is  established  between  RE  link 
management  and  the  transceiver,  the  transceiver  shall  send  Eink  Metric  TEV(s)  at  a  minimum  of 
once  every  epoch. 

28.4.4  Heartbeat  Processing 

The  initial  heartbeat  value  is  obtained  through  configuration  via  an  MDE  configuration 
file.  An  RE  network  message  containing  a  Heartbeat  TEV  shall  be  used  to  overwrite  the  current 
value  of  its  heartbeat  value. 

The  Heartbeat  TEV,  which  is  described  in  more  detail  in  Chapter  24,  provides  a  numeric 
timeout  value  that  represents  the  number  of  epochs  in  the  future  that  the  transmitting  entity  is 
authorized  to  execute  TxOps.  These  TEVs  are  generated  by  the  RE  link  management  and  sent  to 
the  transmitting  entities.  The  timeout  value  of  a  newly  received  Heartbeat  TEV  shall  replace  the 
existing  heartbeat  timeout  value.  It  is  the  responsibility  of  the  RE  link  management  to  issue  new 
Heartbeat  TEVs  before  the  heartbeat  timeout  expires.  A  transmitting  entity  whose  heartbeat 
value  has  reached  zero  shall  remove  all  active  TxOps,  and  the  transmitting  entity  shall  not 
transmit  further  until  it  receives  a  non-zero  heartbeat  value,  either  from  an  RE  network  message 
with  a  Heartbeat  TEV  or  through  reconfiguration  with  an  MDE  configuration  file. 

While  the  heartbeat  timeout  value  of  a  transmitting  entity  is  zero,  any  newly  received 
TxOp  Assignment  TEVs  shall  be  discarded.  A  Heartbeat  TEV  may  be  sent  in  the  same  RE 
network  message  alongside  TxOp  Assignment  TEVs.  Because  TEVs  within  an  RE  network 
message  are  processed  in  order,  the  Heartbeat  TEV  should  be  first  before  any  TxOp  Assignment 


TEV. 


A  heartbeat  value  is  a  global  configuration  parameter  that  affects  all  RE  interfaces  on  the 
entity.  Reception  of  an  RE  network  message  containing  a  heartbeat  TEV  from  RE  link 
management  that  is  directed  to  any  RE  network  interface  on  the  receiving  entity  will  refresh  the 
heartbeat  counter  for  all  RE  network  interfaces  (e.g.,  links). 

Heartbeat  values  that  are  set  to  the  value  representing  an  infinite  lifetime  shall  never 
expire;  however,  these  values  may  be  overwritten  through  RE  network  messaging  as  described 
above. 

The  current  heartbeat  value  shall  be  provided  in  the  MDE  file  produced  by  a  transceiver 
during  an  MDE  export  operation. 
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NOTE 


In  the  event  of  a  power  interruption,  the  transceiver  should  store  its  current 
heartbeat  timeout  value.  The  heartbeat  value  should  be  used  after  the  transceiver 
boots  back  up,  but  only  after  the  proper  number  of  decrements  to  the  timeout  are 
made.  The  number  of  epochs  missed  due  to  the  transceiver  being  rebooted  or 
powered  off  should  be  used  to  determine  the  proper  number  of  decrements. 


28.5  Tunnel  Management 

Network  tunnels  provide  a  mechanism  to  ease  the  complexity  of  transporting  TmNS- 
based  data  and  command  and  control  network  packets  across  pre-existing  networks.  For 
example,  routing,  QoS,  multicast  delivery,  and  handoff  can  be  supported  by  the  tunnel,  thereby 
not  requiring  customized  range  IT  solutions.  These  tunnels  can  be  created,  removed,  and 
adapted  through  management  functions. 

Tunnel  management  provides  support  for  multiple  receiving  entities  of  a  single 
transmission  in  a  seamless  manner  (message-selection-from-many).  Doing  this  allows  the 
network  to  appear  as  a  packet  funnel;  that  is,  it  makes  the  multiple  packet  receptions  appear  as  a 
single  packet  reception.  Likewise,  tunnel  management  supports  the  selection  of  a  particular 
transmitting  entity  from  a  set  of  possible  transmitting  entities  (transmitter-selection)  such  that  it 
can  appear  as  a  single  continuous  transmission  stream,  even  in  dynamic  switching  scenarios. 
Receiving  entity  message-selection-from-many  is  a  process  of  allowing  multiple  receivers  to 
receive  the  same  RF  transmissions  from  a  single  source.  The  selection  portion  chooses  the  first 
received  packet  and  forwards  it  on  to  its  destination  while  all  duplicate  packets  received  are 
discarded.  The  transmitter-selection  portion  of  tunnel  management  allows  for  the  dynamic 
switching  of  transmitting  entities. 


NOTE^ 

Message-selection-from-many  and  transmitter-selection  capabilities 

of  tunnel  management  can  be  utilized  on  a  range  to  support  handoff. 

r 

The  message-selection-from-many  choice  can  support  a  kind  of 

packet-based  source  selection  for  the  air-to-ground  transmissions. 

The  transmitter-selection  involves  the  selection  of  the  transmitting 

entity  for  delivering  packets  to  the  target  network. 

Tunnel  management  shall  be  implemented  by  using  virtual  network  interfaces,  which 
appear  just  like  any  real  network  interface  to  the  host  operating  system,  but  they  can  also  be 
accessed  by  application  programs.  These  virtual  interfaces  are  commonly  called  “tuns”  and  are 
first-class  interfaces  in  Linux -based  operating  systems.  Implementations  for  Windows-based 
operating  systems  and  macOS-based  operating  systems  are  also  prevalent.  Open-source 
examples  of  tun  implementation  are  available  on  the  Internet.  The  following  links  contain 
information  regarding  tuns  for  Linux,  Windows,  and  macOS,  respectively: 

•  https://kernel.org/doc/Documentation/networking/tuntap.txt  (See  Appendix  28-A) 

•  https://communitv.openvpn.net/openvpn/wiki/ManagingWindowsTAPDrivers 

•  http://tuntaposx.sourceforge.net  (See  Appendix  28-B) 


The  overall  process  of  using  the  virtual  interfaces  and  tunnel  selection  process  is  a 
functionality  referred  to  as  the  TmNS  Source  Selector  (TSS)  capability.  The  TmNS -compliant 
transceivers  shall  provide  tuns  that  can  be  connected  through  TCP  tunnels  by  RF  link 
management.  Likewise,  RF  link  management  shall  provide  tuns  to  connect  to  TmNS-compliant 
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transceivers.  These  tuns  are  referred  to  as  TSS  interfaces.  The  TSS  tunnels  between  TSS 
interfaces  shall  be  implemented  using  Secure  Sockets  Layer  over  TCP.  See  Chapter  22, 
Subsection  22.4.3  for  more  information  on  SSL  and  Subsection  22.4.1  for  more  information  on 
TCP. 

28.5.1  Tunnel  Connection 

A  TSS  client  initiates  a  TCP  connection  to  the  TSS  listening  port  on  a  TSS  server  in 
order  to  establish  the  connection  to  be  used  as  the  tunnel.  The  default  port  for  listening  to 
incoming  TSS  connections  shall  be  55000. 

28.5.2  TSS  Interface  Initialization 

Each  time  a  TCP  connection  is  established  between  a  TSS  client  and  the  target  TSS 
server,  the  TSS  initialization  sequence  shall  occur.  Each  tunnel  end  point  shall  follow  its  own 
initialization  sequence. 

28.5.2. 1  Initialization  of  TSS  Server  Interface 

The  TSS  server  shall  create  its  virtual  interface,  apply  interface  properties  to  it,  and  then 
bring  up  the  interface.  Once  the  interface  is  up  and  active  on  the  TSS  server,  it  shall  send  its 
virtual  interface  properties  through  the  tunnel  to  the  connected  TSS  client.  The  interface 
properties  shall  be  carried  through  TSS  initialization  messages,  which  are  described  in  Chapter 
24  (including  the  order  in  which  they  shall  be  sent).  The  TSS  initialization  messages  shall  be  the 
first  messages  sent  through  the  tunnel.  After  these  six  messages  are  sent,  any  post-initialization 
operations,  such  as  routing  table  updates,  may  be  made. 

The  TSS  interface  parameter  values  for  TSS  servers  may  be  initialized  during 
configuration  through  MDE.  Default  values  shall  be  used  if  not  explicitly  described  in  MDE 
during  component  configuration.  Default  values  for  a  TSS  server  interface  are  shown  in  Table 
28-3. 


Table  28-3.  Default  Interface  Values  for  TSS  Server  Interfaces 

Value 

Description 

192.168.1.255 

Broadcast  address  to  associate  with  the  TSS  server  interface 

192.168.1.1 

IP  address  to  assign  to  this  TSS  server  interface 

55000 

Port  to  listen  on  for  incoming  TCP  connection 

tapO 

Name  to  give  the  TSS  server  interface 

255.255.255.0 

Netmask  of  the  TSS  server  interface 

28.5.2.2  Initialization  of  TSS  Client  Interface 

The  TSS  client  shall  create  a  separate  virtual  interface  for  each  TSS  server  that  a  TSS 
client  establishes  a  TSS  tunnel  with.  The  virtual  interface  shall  have  its  interface  properties 
applied,  and  then  the  interface  shall  be  brought  up.  Once  it  is  up,  it  shall  listen  for  the  six  TSS 
initialization  messages  being  sent  from  the  TSS  server  interface  of  the  connected  TSS  server. 
Once  the  six  messages  are  received,  the  TSS  client  interface  has  been  initialized.  If  the  interface 
is  to  be  immediately  available  for  routing,  a  post-initialization  routing  rule  should  be  added  to  the 
TSS  client’s  routing  table. 
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28.5.3  Tunnel  Operation 

From  the  RF  link  management  perspective,  transmitter- selection  IP  routing  shall  be 
performed  by  writing  to  only  one  of  the  tunnels  associated  with  the  destination  IP  address. 
Message-selection-from-many  shall  use  the  Cyclic  Redundancy  Check  field  of  the  TSS  data 
message  in  order  to  identify  duplicated  received  packets.  For  message-selection-from-many,  the 
first  instance  of  a  received  IP  packet  shall  be  forwarded  towards  its  destination.  All  subsequent 
duplicate  packets  shall  be  discarded. 

With  the  exception  of  TSS  initialization  messages,  all  packets  that  traverse  the  tunnels  are 
TSS  data  messages,  and  they  shall  conform  to  the  structure  described  in  Chapter  24. 

28.5.4  Tunnel  Selection 

When  there  are  multiple  potential  RF  links  (e.g.,  routes)  to  a  single  receiving  entity,  the 
RF  link  management  shall  route  all  IP  traffic  to  the  target  network  through  the  appropriate 
tunnel.  The  appropriate  tunnel  is  defined  as  the  tunnel  whose  endpoint  is  associated  with  the 
transmitting  entity  that  is  actively  being  scheduled  with  TxOps  for  the  target  network. 


NOT 


During  handoff  scenarios,  it  is  expected  that  RF  link 
management  will  manage  the  tunnel  selection  in  conjunction 
with  the  TxOp  scheduling  of  the  transmitting  entities. 
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Appendix  28-A 

Documentation  of  TunTap  Device  Driver  for  Linux 


NOTE^ 

This  appendix  was  written  and  published  by  somebody  not 

r 

affiliated  with  the  RCC;  therefore,  it  is  edited  only  for 

formatting  and  not  for  content. 

Universal  TUN/TAP  device  driver. 

Copyright  (C)  1999-2000  Maxim  Krasnyansky  <max_rrLk@  yahoo. com> 

Linux,  Solaris  drivers 

Copyright  (C)  1999-2000  Maxim  Krasnyansky  <max_mk@  yahoo. com> 

FreeBSD  TAP  driver 

Copyright  (c)  1999-2000  Maksim  Yevmenkin  <m_evmenkin@yahoo.com> 

Revision  of  this  document  2002  by  Florian  Thiel  <florian.thiel@gmx.net> 

1.  Description 

TUN/TAP  provides  packet  reception  and  transmission  for  user  space  programs.  It  can  be  seen  as 
a  simple  Point-to-Point  or  Ethernet  device,  which,  instead  of  receiving  packets  from  physical 
media,  receives  them  from  user  space  program  and  instead  of  sending  packets  via  physical  media 
writes  them  to  the  user  space  program. 

In  order  to  use  the  driver  a  program  has  to  open  /dev/net/tun  and  issue  a  corresponding  ioctl()  to 
register  a  network  device  with  the  kernel.  A  network  device  will  appear  as  tunXX  or  tapXX, 
depending  on  the  options  chosen.  When  the  program  closes  the  file  descriptor,  the  network 
device  and  all  corresponding  routes  will  disappear. 

Depending  on  the  type  of  device  chosen  the  userspace  program  has  to  read/write  IP  packets  (with 
tun)  or  ethemet  frames  (with  tap).  Which  one  is  being  used  depends  on  the  flags  given  with  the 
ioctl(). 

The  package  from  http://vtun.sourceforge.net/tun  contains  two  simple  examples  for  how  to  use 
tun  and  tap  devices.  Both  programs  work  like  a  bridge  between  two  network  interfaces. 
br_select.c  -  bridge  based  on  select  system  call. 
br_sigio.c  -  bridge  based  on  async  io  and  SIGIO  signal. 

However,  the  best  example  is  VTun  http://vtun.sourceforge.net :)) 

2.  Configuration 
Create  device  node: 

mkdir  /dev/net  (if  it  doesn't  exist  already) 
mknod  /dev/net/tun  c  10  200 
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Set  permissions: 

e.g.,  chmod  0666  /dev/net/tun 

There's  no  harm  in  allowing  the  device  to  be  accessible  by  non-root  users,  since 
CAP_NET_ADMIN  is  required  for  creating  network  devices  or  for  connecting  to  network 
devices  that  aren't  owned  by  the  user  in  question.  If  you  want  to  create  persistent  devices  and 
give  ownership  of  them  to  unprivileged  users,  then  you  need  the  /dev/net/tun  device  to  be  usable 
by  those  users. 

Driver  module  autoloading 

Make  sure  that  "Kernel  module  loader"  -  module  auto-loading  support  is  enabled  in  your  kernel. 
The  kernel  should  load  it  on  first  access. 

Manual  loading 

insert  the  module  by  hand: 
modprobe  tun 

If  you  do  it  the  latter  way,  you  have  to  load  the  module  every  time  you  need  it,  if  you  do  it  the 
other  way  it  will  be  automatically  loaded  when  /dev/net/tun  is  being  opened. 

3.  Program  interface 

3.1  Network  device  allocation: 


char  *dev  should  be  the  name  of  the  device  with  a  format  string  (e.g.,  "tun%d"),  but  (as  far  as  I 
can  see)  this  can  be  any  valid  network  device  name.  Note  that  the  character  pointer  becomes 
overwritten  with  the  real  device  name  (e.g.,  "tunO") 


#include  <linux/if.h> 
#include  <linux/if_tun . h> 


int  tun_alloc(char  *dev) 

{ 

struct  ifreq  ifr; 
int  fdj  err; 

if(  (fd  =  open( "/dev/net/tun" j  0_RDWR))  <  0  ) 
return  tun_alloc_old(dev) ; 

memset(&ifrj  0j  sizeof (if r) ) ; 


/*  Flags:  IFF_TUN 

*  IFF_TAP 

* 


-  TUN  device  (no  Ethernet  headers) 

-  TAP  device 


*  IFF_N0_PI  -  Do  not  provide  packet  information 

*/ 

ifr . ifr_flags  =  IFF_TUN; 
if(  *dev  ) 

strncpy(ifr . ifr_namej  deVj  IFNAMSIZ); 
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if(  (err  =  ioctl(fdj  TUNSETIFFj  (void  *)  &ifr))  <  0  ){ 
close(fd) ; 
return  err; 

} 

strcpy(deVj  ifr . ifr_name) ; 
return  fd; 

} 

3.2  Frame  format: 

If  flag  IFF_NO_PI  is  not  set  each  frame  format  is: 

Flags  [2  bytes] 

Proto  [2  bytes] 

Raw  protocol(IP,  IPv6,  etc)  frame. 

3.3  Multiqueue  tuntap  interface: 

From  version  3.8,  Linux  supports  multiqueue  tuntap,  which  can  uses  multiple  file  descriptors 
(queues)  to  parallelize  packets  sending  or  receiving.  The  device  allocation  is  the  same  as  before, 
and  if  user  wants  to  create  multiple  queues,  TUNSETIFF  with  the  same  device  name  must  be 
called  many  times  with  IFF_MULTI_QUEUE  flag. 

char  *dev  should  be  the  name  of  the  device,  queues  is  the  number  of  queues  to  be  created,  fds  is 
used  to  store  and  return  the  file  descriptors  (queues)  created  to  the  caller.  Each  file  descriptor 
were  served  as  the  interface  of  a  queue  that  could  be  accessed  by  userspace. 

#include  <linux/if.h> 

#include  <linux/if_tun . h> 

int  tun_alloc_mq(char  *deVj  int  queues^  int  *fds) 

{ 

struct  ifreq  ifr; 
int  fdj  errj  i; 

if  (!dev) 

return  -1; 

memset(&ifrj  0j  sizeof (if r) ) ; 

/*  Flags:  IFF_TUN  -  TUN  device  (no  Ethernet  headers) 

*  IFF_TAP  -  TAP  device 

* 

*  IFF_N0_PI  -  Do  not  provide  packet  information 

*  IFF_MULTI_QUEUE  -  Create  a  queue  of  multiqueue  device 
*! 

ifr. if r_f lags  =  IFF_TAP  |  IFF_N0_PI  |  IFF_MULTI_QUEUE; 
strcpy(ifr . ifr_namej  dev); 

for  (i  =  0;  i  <  queues;  i-H+)  { 

if  ((fd  =  open( "/dev/net/tun" j  0_RDWR))  <  0) 
goto  err; 

err  =  ioctl(fdj  TUNSETIFFj  (void  *)&ifr); 
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if  (err)  { 
close(fd) ; 
goto  err; 

} 

fds[i]  =  fd; 

} 

return  0; 

err: 

for  (--i;  i  >=  0;  i--) 
close(fds [i] ) ; 
return  err; 

} 

A  new  ioctl(TUNSETQUEUE)  were  introduced  to  enable  or  disable  a  queue.  When  calling  it 
with  IEE_DETACH_QUEUE  flag,  the  queue  were  disabled.  And  when  calling  it  with 
IEE_ATTACH_QUEUE  flag,  the  queue  were  enabled.  The  queue  were  enabled  by  default  after 
it  was  created  through  TUNSETIEE. 

fd  is  the  file  descriptor  (queue)  that  we  want  to  enable  or  disable,  when  enable  is  true  we  enable 
it,  otherwise  we  disable  it 

#include  <linux/if.h> 

#include  <linux/if_tun . h> 

int  tun_set_queue(int  fdj  int  enable) 

{ 

struct  ifreq  ifr; 
memset(&ifrj  0j  sizeof (if r) ) ; 
if  (enable) 

ifr. if r_f lags  =  IFF_ATTACH_QUEUE; 
else 

ifr. if r_f lags  =  IFF_DETACH_QUEUE; 
return  ioctl(fdj  TUNSETQUEUEj  (void  *)&ifr); 

} 

Universal  TUN/TAP  device  driver  Erequently  Asked  Question. 

1 .  What  platforms  are  supported  by  TUN/TAP  driver  ? 

Currently  driver  has  been  written  for  3  Unices: 

Einux  kernels  2.2.x,  2.4.x 
EreeBSD  3.x,  4.x,  5.x 
Solaris  2.6,  7.0,  8.0 

2.  What  is  TUN/TAP  driver  used  for? 
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As  mentioned  above,  main  purpose  of  TUN/TAP  driver  is  tunneling.  It  is  used  by  VTun 
(http  ://vtun .  sourceforge  .net) . 

Another  interesting  application  using  TUN/TAP  is  pipsecd 

(http://perso.enst.fr/~beyssac/pipsec/),  a  userspace  IPSec  implementation  that  can  use  complete 
kernel  routing  (unlike  FreeS/WAN). 

3.  How  does  Virtual  network  device  actually  work  ? 

Virtual  network  device  can  be  viewed  as  a  simple  Point-to-Point  or  Ethernet  device,  which 
instead  of  receiving  packets  from  a  physical  media,  receives  them  from  user  space  program  and 
instead  of  sending  packets  via  physical  media  sends  them  to  the  user  space  program. 

Let's  say  that  you  configured  IPX  on  the  tapO,  then  whenever  the  kernel  sends  an  IPX  packet  to 
tapO,  it  is  passed  to  the  application  (VTun  for  example).  The  application  encrypts,  compresses 
and  sends  it  to  the  other  side  over  TCP  or  UDP.  The  application  on  the  other  side  decompresses 
and  decrypts  the  data  received  and  writes  the  packet  to  the  TAP  device,  the  kernel  handles  the 
packet  like  it  came  from  real  physical  device. 

4.  What  is  the  difference  between  TUN  driver  and  TAP  driver? 

TUN  works  with  IP  frames.  TAP  works  with  Ethernet  frames. 

This  means  that  you  have  to  read/write  IP  packets  when  you  are  using  tun  and  ethemet  frames 
when  using  tap. 

5.  What  is  the  difference  between  BPE  and  TUN/TAP  driver? 

BPE  is  an  advanced  packet  filter.  It  can  be  attached  to  existing  network  interface.  It  does  not 
provide  a  virtual  network  interface.  A  TUN/TAP  driver  does  provide  a  virtual  network  interface 
and  it  is  possible  to  attach  BPE  to  this  interface. 

6.  Does  TAP  driver  support  kernel  Ethernet  bridging? 

Yes.  Linux  and  EreeBSD  drivers  support  Ethemet  bridging. 
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Appendix  28-B 

Documentation  of  TunTap  Project  for  macOS 


NOTE^ 

This  appendix  was  written  and  published  by  somebody  not 

r 

affiliated  with  the  RCC;  therefore,  it  is  edited  only  for 

formatting  and  not  for  content. 

Overview 
What  is  it? 

The  TunTap  project  provides  kernel  extensions  for  Mac  OS  X  that  allow  to  create  virtual 
network  interfaces.  From  the  operating  system  kernel's  point  of  view,  these  interfaces  behave 
similar  to  physical  network  adapters  such  as  an  Ethernet  network  interface.  However,  the 
virtual  interface  does  not  send  the  packets  into  a  wire,  but  makes  them  available  to  programs 
running  in  the  system. 

The  software  comes  as  a  pair  of  kernel  extensions  that  create  virtual  network  interfaces  on  the 
IP  and  Ethernet  level,  respectively.  These  kind  of  network  interfaces  are  commonly  referred  to 
as  tun  and  tap  devices  on  Unix-like  platforms.  This  way  of  interfacing  with  the  operating 
system's  network  stack  is  available  on  many  platforms  (cf.  the  <a 
href="http://en. Wikipedia. org/wiki/TUN/TAP">TUN/TAP</a>  Wikipedia  article). 

Who  needs  it? 

By  design,  virtual  network  interfaces  can  be  very  flexibly  used  by  any  program  that  wants  to 
receive  packets  from  and  inject  them  into  the  network  stack.  Generally,  tun  and  tap  devices 
are  most  commonly  used  in  two  distinct  application  scenarios:  The  first  one  is  VPN  software 
(such  as  <a  href="http://openvpn.net">OpenVPN</a>).  In  this  scenario,  the  kernel  sends  its 
network  packets  to  the  tun  or  tap  devices.  The  VPN  software  will  then  encrypt  and  forward 
them  to  the  other  side  of  the  VPN  tunnel  where  they  get  decrypted  and  delivered  to  their 
destination.  The  second  area  in  which  tun  and  tap  devices  are  popular  are  system 
virtualization/emulation  packages.  In  this  case,  the  virtualized  operating  system  instance  talks 
to  a  fake  network  device  (commonly  a  virtual  Ethernet  adapter).  The  virtualization  software 
then  creates  a  tap  device  and  interconnects  the  two  such  that  the  host  system  can  talk  to  the 
guest  and  vice  versa. 

How  does  it  work? 

The  TunTap  package  is  comprised  of  a  pair  of  kernel  extensions,  one  providing  tun  and  one 
providing  tap  interfaces.  They  create  a  set  of  character  devices  dev/tunX  and  /dev/tapX, 
respectively,  where  X  is  a  number  between  zero  and  the  maximum  number  of  supported  virtual 
interfaces.  Once  an  application  opens  the  character  device,  say  <code>/dev/tapO</code>,  a 
virtual  network  interface  is  created  in  the  system,  which  will  be  named  accordingly,  i.e.,  tap0. 
The  network  interface  can  be  assigned  addresses  just  like  any  other  network  interfaces.  After 
configuring  the  interface,  packets  that  the  kernel  sends  through  this  interface  (as  determined 
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by  the  routing  table)  can  be  read  one  packet  at  a  time  from  the  character  device.  Likewise, 
packets  written  to  the  character  device  will  be  injected  into  the  kernel's  network  stack.  For  tun 
interfaces,  the  packets  that  are  read  and  written  are  IP  packets.  For  tap  interfaces,  the  packet 
format  is  Ethernet  frames. 

Mailing  list 

There  is  a  mailing  list  available  through  the  Sourceforge  project  that  is  meant  for  general 
discussion  about  the  TunTap  software,  asking  questions,  reporting  bugs  etc.  It  is  called 
tuntaposx-users.  If  you  are  interested,  you  can  register 

(https://lists.sourceforge.net/lists/listinfo/tuntaposx-users)  or  have  a  look  at  the  archives 
(http://sourceforge.net/mailarchive/forum.php7forum  name=tuntaposx-users). 

Donations 

So  far,  I  have  spent  my  spare  time  to  run  this  project.  If  you  want  to  show  your  gratitude  or 
support  further  maintenance  or  development  of  the  software,  you  can  donate  either  via  the 
Sourceforge  donation  system  or  directly  to  me  via  PayPal,  just  click  the  appropriate  button 
below.  In  either  case,  your  money  enables  me  to  buy  copies  of  upcoming  Mac  OS  X  releases  as 
well  as  development  machines.  A  huge  thank  you  goes  to  the  nice  people  at  mozilla.com  who 
have  given  me  the  Mac  Mini  I  currently  use  as  development  machine. 
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Acronyms 


dB 

decibel 

FM 

frequency  modulation 

IF 

intermediate  frequency 

PAM 

pulse  amplitude  modulation 

NRZ 

non-retum-to-zero 

RZ 

return-to-zero 
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ANNEX  A.l 

Pulse  Amplitude  Modulation  Standards 


1.  General 

This  standard  defines  the  recommended  pulse  train  structure  and  design  characteristics 
for  the  implementation  of  pulse  amplitude  modulation  (PAM)  telemetry  systems.  The  PAM  data 
is  transmitted  as  time  division  multiplexed  analog  pulses  with  the  amplitude  of  the  information 
channel  pulse  being  the  analog-variable  parameter. 

2.  Frame  and  Pulse  Structure 

Each  frame  consists  of  a  constant  number  of  time-sequenced  channel  intervals.  The 
maximum  shall  be  128-channel  time  intervals  per  frame,  including  the  intervals  devoted  to 
synchronization  and  calibration.  The  pulse  and  frame  structure  shall  conform  to  either  Figure 
Error!  No  text  of  specified  style  in  document.- 1  or  Figure  Error!  No  text  of  specified  style  in 
document.-2. 


Figure  Error!  No  text  of  specified  style  in  document.- 1 .  50  percent  duty  cycle  PAM  with 

amplitude  synchronization 


NOTE^ 

A  20-25  percent  deviation  reserved  for  pulse 

r 

synchronization  is  recommended. 
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Figure  Error!  No  text  of  specified  style  in  document.-2.  100  percent  duty  cycle  PAM  with 

amplitude  synchronization 


2.1.  Commutation  Pattern 

The  information  channels  are  allocated  equal  and  constant  time  intervals  within  the  PAM 
frame.  Each  interval  (“T”  in  Figure  Error!  No  text  of  specified  style  in  document.- 1  and  Figure 
Error!  No  text  of  specified  style  in  document. -2)  contains  a  sample  pulse  beginning  at  the  start  of 
the  interval  and  having  amplitude  determined  by  the  amplitude  of  the  measurand  of  the 
corresponding  information  channel  according  to  a  fixed  relationship  (usually  linear)  between  the 
minimum  level  (zero  amplitude)  and  the  maximum  level  (full-scale  amplitude).  For  a  50-percent 
duty  cycle  (return-to-zero  [RZ]-PAM),  the  zero  level  shall  be  20  to  25  percent  of  the  full 
amplitude  level  as  shown  in  Figure  Error!  No  text  of  specified  style  in  document.- 1.  The  pulse 
width  shall  be  the  same  in  all  time  intervals  except  for  the  intervals  devoted  to  synchronization. 
The  duration  shall  be  either  0.5T  +0.05,  as  shown  in  Figure  Error!  No  text  of  specified  style  in 
document.- 1,  or  T  +0.05,  as  shown  in  Figure  Error!  No  text  of  specified  style  in  document. -2. 

2.2.  In-Flight  Calibration 

It  is  recommended  that  in-flight  calibration  be  used  and  channels  1  and  2,  immediately 
following  the  frame  synchronization  interval,  be  used  for  zero  and  full-scale  calibration.  For  RZ- 
PAM,  channel  3  may  be  used  for  an  optional  half-scale  calibration,  and  for  non-retum-to-zero 
(NRZ)-PAM,  the  channel  interval  preceding  channel  1  may  be  used  for  half-scale  calibration  if 
set  to  50  percent. 

2.3.  Frame  Synchronization  Interval 

Each  frame  is  identified  by  the  presence  within  it  of  a  synchronization  interval. 

2.3.1.  Fifty  Percent  Duty  Cycle  (RZ-PAM) 

The  synchronization  pattern  interval  shall  have  a  duration  equal  to  two  information 
channel  intervals  (2T)  and  shall  be  full-scale  amplitude  for  1 .5T  followed  by  the  reference  level 
or  zero  baseline  for  0.5T  (see  Figure  Error!  No  text  of  specified  style  in  document.- 1). 
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2.3.2.  One  Hundred  Percent  Duty  Cycle  (NRZ-PAM) 

The  synchronization  pattern  is  in  the  order  given:  zero  level  for  a  period  of  T,  full-scale 
amplitude  for  a  period  of  3T,  and  a  level  not  exceeding  50-percent  full-scale  amplitude  for  a 
period  T  (see  Figure  Error!  No  text  of  specified  style  in  document.-2). 

2.4.  Maximum  Pulse  Rate 

The  maximum  pulse  rate  should  not  be  greater  than  that  permitted  by  the  following 
subparagraphs. 

2.4.1.  PAM/FM/FM 

The  reciprocal  of  the  shortest  interval  between  transitions  in  the  PAM  pulse  train  shall 
not  be  greater  than  one-fifth  of  the  total  (peak-to-peak)  deviation  specified  in  Chapter  3  (Table  3- 
1,  Table  3-2,  and  Table  3-3)  for  the  FM  subcarrier  selected. 

2.4.2.  PAM/FM 

The  reciprocal  of  the  shortest  interval  between  transitions  in  the  PAM  pulse  train  shall  be 
limited  by  whichever  is  the  narrower  of  the  following: 

a.  One-half  of  the  3-dB  frequency  of  the  premodulation  filter  when  employed. 

b.  One-fifth  of  the  intermediate  frequency  (IF)  bandwidth  (3  dB  points)  selected  from  the  IF 
bandwidths  listed  in  Chapter  2,  Table  2-7. 

3.  Frame  and  Pulse  Rate 

The  frame  and  pulse  parameters  listed  below  may  be  used  in  any  combination: 

•  a  minimum  rate  of  0.125  frames  per  second,  and 

•  a  maximum  pulse  rate  as  specified  in  subparagraphs  2.4.1  and  2.4.2  above. 

3.1.  Long-Term  Accuracy  and  Stability 

During  a  measured  period  of  desired  data,  the  time  between  the  occurrences  of 
corresponding  points  in  any  two  successive  frame  synchronization  intervals  should  not  differ 
from  the  reciprocal  of  the  specified  nominal  frame  rate  by  more  than  5  percent  of  the  nominal 
period. 

3.2.  Short-Term  Stability 

During  a  measured  period  (P),  containing  1000-channel  intervals,  the  time  between  the 
start  of  any  two  successive  channel  intervals  (synchronization  intervals  excepted)  should  not 
differ  from  the  average  channel  interval  established  by  the  formula 


1000 


by  more  than  1  percent  of  the  average  interval. 
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3.3.  Multiple  and  Submultiple  Sampling  Rates 

Data  multiplexing  at  sampling  rates  which  are  multiples  and  submultiples  of  the  frame 
rate  is  permissible. 

3.3.1.  Submultiple  Frame  Synchronization 

The  beginning  of  the  longest  submultiple  frame  interval  is  identified  by  the  transmission 
of  a  synchronization  pattern.  All  other  submultiple  frames  have  a  fixed  and  known  relationship 
to  the  identified  submultiple  frames. 

33.1.1.  Fifty  Percent  Duty  Cycle  ( RZ ) 

The  synchronization  pattern  has  a  full-scale  amplitude  pulse  in  two  successive 
occurrences  of  channel  intervals  allocated  to  data  channels  of  the  identified  submultiple  frame. 
The  first  such  pulse  has  a  duration  equal  to  the  channel  interval;  the  second  pulse  immediately 
follows  the  first  pulse  and  has  a  duration  nominally  one-half  the  channel  interval.  There  is  no 
return  to  zero  between  the  two  pulses. 

3. 3. 1.2.  One  Hundred  Percent  Duty  Cycle  (NRZ) 

The  synchronization  pattern  has  information  in  five  successive  occurrences  of  a  channel 
interval  allocated  to  data  channels  of  the  identified  submultiple  frame.  The  amplitude  of  the  data 
channels  assigned  for  synchronization  is  shown  in  the  following  items. 

a.  First  occurrence  -  zero  amplitude. 

b.  Second,  third,  and  fourth  occurrences  -  full-scale  amplitude. 

c.  Fifth  occurrence  -  not  more  than  50  percent  of  full-scale  amplitude. 

3.3.2.  Maximum  Submultiple  Frame  Length 

The  interval  of  any  submultiple  frame,  including  the  time  devoted  to  synchronizing 
information,  shall  not  exceed  128  times  the  interval  of  the  frame  in  which  it  occupies  a  recurring 
position. 

4.  Frequency  Modulation 

The  frequency  deviation  of  an  FM  carrier  or  subcarrier,  which  represents  the  maximum 
and  minimum  amplitude  of  a  PAM  waveform,  should  be  equal  and  opposite  with  respect  to  the 
assigned  carrier  or  subcarrier  frequency.  The  deviation  should  be  the  same  for  all  occurrences  of 
the  same  level. 

5.  Premodulation  Filtering 

A  maximally  linear  phase  response,  premodulation  filter,  is  recommended  to  restrict  the 
radiated  spectrum  (see  Chapter  2  Appendix  2- A). 

****  END  OF  ANNEX  A.l  **** 
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Acronyms 


|am 

micrometer 

ANSI 

American  National  Standards  Institute 

b/mm 

bits  per  millimeter 

Bi(^ 

bi-phase 

BifL 

bi-phase-level 

dB 

decibel 

dc 

direct  current 

FM 

frequency  modulation 

ft 

feet 

HDD 

High-Density  Digital 

HDDR 

High-Density  Digital  Recording 

HE 

High-Energy 

HR 

High-Resolution 

Hz 

hertz 

in 

inch 

in/s 

inches  per  second 

IRIG 

Inter-Range  Instrumentation  Group 

ISO 

International  Organization  for  Standardization 

kA/m 

kiloamps  per  meter 

kb/in 

kilobits  per  inch 

kb/s 

kilobits  per  second 

kHz 

kilohertz 

Mb/s 

megabits  per  second 

MCT 

manufacturer’s  centerline  tape 

MHz 

megahertz 

mm 

millimeter 

mm/s 

millimeters  per  second 

MSCT 

manufacturer’s  secondary  centerline  tape 

NRZ-L 

non-retum-to-zero  level 

PCM 

pulse  code  modulation 

RM 

relative  humidity 

rms 

root  mean  square 

RNRZ-L 

randomized  non-retum-to-zero  level 

SNR 

signal-to-noise  ratio 

UBE 

upper  band  edge 

V 

volt 

Vdc 

volts  direct  current 

WRT 

working  reference  tape 
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ANNEX  A.2 

Magnetic  Tape  Recorder  and  Reproducer  Information 

and  Use  Criteria 

1.  Other  Instrumentation  Magnetic  Tape  Recorder  Standards 

The  X3B6  Committee  of  the  American  National  Standards  Institute  (ANSI)  and  the 
International  Organization  for  Standardization  (ISO)  have  prepared  several  standards  for 
magnetic  tape  recording  of  instrumentation  data.  Documents  may  be  obtained  by  contacting  the 
ANSI  web  site  (http://webstore.ansi.org). 

Documentation  applicable  to  this  annex  is  identified  in  the  following  bullets. 

•  ISO  1860  (1986),  Information  Processing  -  Precision  reels  for  magnetic  tape  used  in 
interchange  instrumentation  applications. 

•  ISO  6068  (1985),  Information  Processing  -  Recording  characteristics  of  instrumentation 
magnetic  tape  (including  telemetry  systems)  -  interchange  requirements. 

•  ISO/IEC  TR  6371:1989,  Information  Processing  -  Interchange  practices  and  test  methods 
for  unrecorded  instrumentation  magnetic  tape. 

•  ISO/IEC  8441/1:1991,  Information  technology  -  High  Density  Digital  Recording 
(HDDR)  -  Part  1:  Unrecorded  magnetic  tape  for  HDDR  applications. 

•  ISO/IEC  8441/2:1991,  Information  technology  -  High  Density  Digital  Recording 
(HDDR)  -  Part  2:  Guide  for  interchange  practice. 

•  ANSI  INCITS  175-1999,  19  mm  Type  ID-1  Recorded  Instrumentation  -  Digital  Cassette 
Tape  Eormat  (formerly  ANSI  X3. 1 75 -1 990). 


2.  Double-Density  Longitudinal  Recording 

Wide-band  double-density  analog  recording  standards  allowing  recording  of  up  to 
4  megahertz  (MHz)  signals  at  3048  mm/s  (120  in/s)  are  included  in  these  standards.  Eor 
interchange  purposes,  either  narrow  track  widths  0.635  mm  (25  mils)  must  be  employed,  or  other 
special  heads  must  be  used.  These  requirements  are  necessary  because  of  the  difficulty  in 
maintaining  individual  head-segment  gap-azimuth  alignment  across  a  head  close  enough  to  keep 
each  track's  response  within  the  +2-dB  variation  allowed  by  the  standards.  Moreover,  at  the 
lower  tape  speeds  employed  in  double-density  recording,  the  38-mm  (1.5-in.)  spacing  employed 
in  interlaced  head  assemblies  result  in  interchannel  time  displacement  variations  between  odd 
and  even  tracks  that  may  be  unacceptable  for  some  applications.  Therefore,  it  was  decided  that  a 
14-track  in-line  configuration  on  25.4-mm  (1-in.)  tape  should  be  adopted  as  a  standard.  This 
configuration  results  in  essentially  the  same  format  as  head  number  one  of  the  28-track  interlaced 
configuration  in  the  standards. 

The  14-track  interlaced  heads  are  not  compatible  with  tapes  produced  on  an  in-line 
standard  configuration.  If  tapes  must  be  interchanged,  either  a  cross-configuration  dubbing  may 
be  required  or  a  change  of  head  assemblies  on  the  reproducing  machine  is  necessary. 
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High  energy  magnetic  tape  is  required  for  double-density  systems.  Such  tapes  are 
available  but  may  require  special  testing  for  applications  requiring  a  low  number  of  dropouts  per 
track. 

2.1.  Other  Track  Configurations 

The  previously  referenced  standards  in  Section  1  include  configurations  resulting  in  7, 

14,  and  21  tracks  in  addition  to  the  14-track  and  28-track  configurations  listed  in  this  annex.  The 
high-density  digital  recording  (HDDR)  standards  also  reference  an  84-track  configuration  on 
50.8-mm  (2-in.)  tape.  Figure  A.2-1  and  Table  A. 2-1  show  the  7-track  on  12.7-mm  (0.5  in.)  tape, 
Table  A. 2-2  shows  the  14-track  on  12.7-mm  (0.5  in.)  tape,  and  Table  A. 2-3  shows  the  42-track 
on  25.4-mm  (1  in.)  tape  configurations. 

2.2.  High-Density  Pulse  Code  Modulation  Recording. 

High-density  digital  recording  systems  are  available  from  most  instrumentation  recorder 
manufacturers.  Such  systems  will  record  at  linear  packing  densities  of  33,000  bits  per  inch  or 
more  per  track.  Special  systems  are  available  for  error  detection  and  correction  with  overhead 
penalties  depending  on  the  type  and  the  sophistication  of  the  system  employed.  The  HDDR 
documents  listed  in  Section  I  reference  six  different  systems  that  have  been  produced;  others  are 
available. 
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Figure  A.2-1.  Record  and  reproduce  head  and  head  segment  identification  and  location  (7-track  interlaced  system) 
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Table  A.2-1.  Dimensions  -  Recorded  Tape  Format  -  7  Tracks 

Interlaced  on  12.7-mm  (0.5  inch)-Wide  Tape  (Refer  to  Figure  A.2-9) 

Parameters 

Millimeters 

Inches 

Track  Width 

1.397  (Max);  1.143  (Min) 

0.050+0.005 

Track  Spacing 

1.778 

0.070 

Fixed  Head  Spacing 

38.125  (Max);  38.075  (Min) 

1.500+0.001 

Adjustable  Head  Spacing 

38.151  (Max);  38.049  (Min) 

1.500+0.002 

Edge  Margin,  Minimum 

0.127 

0.005 

Reference  Track  Location 

1.067  (Max);  0.965  (Min) 

0.040+0.002 

Track  Location  Tolerance 

0.051  (Max);  -0.051  (Min) 

+0.002 

Location  of  n‘**  Track 

Track  Number 

Millimeters 

Inches 

1  (Reference) 

0.000 

0.000 

2 

1.829  (Max);  1.727  (Min) 

0.070 

3 

3.607  (Max);  3.505  (Min) 

0.140 

4 

5.385  (Max);  5.283  (Min) 

0.210 

5 

7.163  (Max);  7.061  (Min) 

0.280 

6 

8.941  (Max);  8.839  (Min) 

0.350 

7 

10.719  (Max);  10.617  (Min) 

0.420 

Table  A.2-2.  Dimensions  -  Recorded  Tape  Format  - 14  Tracks 

Interlaced  on  12.7-mm  (0.5  inch)  Wide  Tape  (Refer  to  Figure  A.2-9) 

Parameters 

Millimeters 

Inches 

Track  Width 

0.660  (Max);  0.610  (Min) 

0.025+0.001 

Track  Spacing 

0.889 

0.035 

Fixed  Head  Spacing 

38.125  (Max);  38.075  (Min) 

1.500+0.001 

Adjustable  Head  Spacing 

38.151  (Max);  38.049  (Min) 

1.500+0.002 

Edge  Margin,  Minimum 

0.127 

0.005 

Reference  Track  Location 

0.546  (Max);  0.470  (Min) 

0.0200+0.001 

Track  Location  Tolerance 

0.038  (Max);  -0.038  (Min) 

+0.0015 

Location  of  n‘**  Track 

Track  Number 

Millimeters 

Inches 

1  (Reference) 

0.000 

0.000 

2 

0.927  (Max);  0.851  (Min) 

0.035 

3 

1.816  (Max);  1.740  (Min) 

0.070 

4 

2.705  (Max);  2.629  (Min) 

0.140 

5 

3.594  (Max);  3.518  (Min) 

0.210 

6 

4.483  (Max);  4.407  (Min) 

0.280 

7 

5.372  (Max);  5.292  (Min) 

0.350 

8 

6.261  (Max);  6.185  (Min) 

0.245 

9 

7.150  (Max);  7. 074  (Min) 

0.280 

10 

8.039  (Max);  7.963  (Min) 

0.315 

A.2-4 


Telemetry  Standards,  IRIG  Standard  106-17  Annex  A. 2,  May  2017 


11 

8.928  (Max);  8.852  (Min) 

0.350 

12 

9.817  (Max);  9.741  (Min) 

0.385 

13 

10.706  (Max);  10.630  (Min) 

0.420 

14 

11.595  (Max);  11.519  (Min) 

0.455 

Table  A.2-3.  Dimensions  -  Recorded  Tape  Format  -  42  Tracks 

Interlaced  on  25.4-mm  (1  inch)  Wide  Tane  (Refer  to  Figure  A.2-9) 

Parameters 

Millimeters 

Inches 

Track  Width 

0.483  (Max);  0.432  (Min) 

0.018+0.001 

Track  Spacing 

0.584 

0.023 

Fixed  Head  Spaeing 

38.125  (Max);  38.075  (Min) 

1.500+0.001 

Adjustable  Head  Spaeing 

38.151  (Max);  38.049  (Min) 

1.500+0.002 

Edge  Margin,  Minimum 

0.305 

0.012 

Reference  Track  Location 

0.737  (Max);  0.660  (Min) 

0.0275+0.015 

Track  Location  Tolerance 

0.025  (Max);  -0.025  (Min) 

+0.0000 

Location  of  n*  Track 

Track  Number 

Millimeters 

Inches 

1  (Reference) 

0.000 

0.000 

2 

0.610  (Max);  0.559  (Min) 

0.023 

3 

1.194  (Max);  1.143  (Min) 

0.046 

4 

1.778  (Max);  1.727  (Min) 

0.069 

5 

2.362  (Max);  2.311  (Min) 

0.092 

6 

2.946  (Max);  2.896  (Min) 

0.115 

7 

3.531  (Max);  3.480  (Min) 

0.138 

8 

4.115  (Max);  4.064  (Min) 

0.161 

9 

4.699  (Max);  4.648  (Min) 

0.184 

10 

5.283  (Max);  5.232  (Min) 

0.207 

11 

5.867  (Max);  5.817  (Min) 

0.230 

12 

6.452  (Max);  6.401  (Min) 

0.253 

13 

7.036  (Max);  6.985  (Min) 

0.276 

14 

7.620  (Max);  7.569  (Min) 

0.299 

15 

8.204  (Max);  8.153  (Min) 

0.322 

16 

8.788  (Max);  8.768  (Min) 

0.345 

17 

9.373  (Max);  9.322  (Min) 

0.368 

18 

9.957  (Max);  9.906  (Min) 

0.397 

19 

10.541  (Max);  10.490  (Min) 

0.414 

20 

11.125  (Max);  11.074  (Min) 

0.437 

21 

11.709  (Max);  11.659  (Min) 

0.460 

22 

12.294  (Max);  12.243  (Min) 

0.483 

23 

12.878  (Max);  12.827  (Min) 

0.506 

24 

13.462  (Max);  13.411  (Min) 

0.529 

25 

14.046  (Max);  13.995  (Min) 

0.552 

26 

14.630  (Max);  14.580  (Min) 

0.575 
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27 

15.215  (Max);  15.164  (Min) 

0.598 

28 

15.799  (Max);  15.748  (Min) 

0.621 

29 

16.383  (Max);  16.332  (Min) 

0.664 

30 

16.967  (Max);  16.916  (Min) 

0.667 

31 

17.551  (Max);  17.501  (Min) 

0.690 

32 

18.136  (Max);  18.085  (Min) 

0.713 

33 

18.720  (Max);  18.660  (Min) 

0.736 

34 

19.304  (Max);  19.253  (Min) 

0.759 

35 

19.888  (Max);  19.837  (Min) 

0.782 

36 

20.472  (Max);  20.422  (Min) 

0.805 

37 

21.057  (Max);  21.006  (Min) 

0.828 

38 

21.641  (Max);  21.590  (Min) 

0.851 

39 

22.225  (Max);  22.174  (Min) 

0.874 

40 

22.809  (Max);  22.758  (Min) 

0.897 

41 

23.393  (Max);  23.343  (Min) 

0.920 

42 

23.978  (Max);  23.927  (Min) 

0.943 

3.  Serial  High-Density  Digital  Recording 

The  following  paragraphs  give  some  baekground  for  seleeting  the  bi-phase  (Bitj))  and 
randomized  non-retum-to-zero-level  (RNRZ-L)  systems  speeified  in  Subparagraph  20.3. 

Serial  HDDR  is  a  method  of  reeording  digital  data  on  a  magnetie  tape  where  the  digital 
data  is  applied  to  one  track  of  the  recording  system  as  a  bi-level  signal.  The  codes  recommended 
for  serial  HDDR  recording  of  telemetry  data  are  Bi(()-level  (Bi(()-L)  and  RNRZ-L  (refer  to 
Paragraph  20). 

In  preparing  Paragraph  20,  the  following  codes  were  considered:  Delay  Modulation 
(Miller  Code),  Miller  Squared,  Enhanced  NRZ,  NRZ  Level,  NRZ  Mark,  and  NRZ  Space.  These 
codes  are  not  recommended  for  interchange  applications  at  the  bit  rates  given  in  Paragraph  20. 

The  properties  of  the  Bi(j)-L  and  RNRZ-L  codes  relevant  to  serial  HDDR  and  the  methods 
for  generating  and  decoding  RNRZ-L  are  described  next.  Recording  with  bias  is  required  for 
interchange  applications  because  reproduce  amplifier  phase  and  amplitude  equalization 
adjustments  for  tapes  recorded  without  bias  usually  differ  from  those  required  for  tapes  recorded 
with  bias. 

The  Bi(j)-L  and  RNRZ-L  codes  were  selected  for  this  standard  because  the  “level” 
versions  are  easier  to  generate  and  are  usually  available  as  outputs  from  bit  synchronizers. 
“Mark”  and  “Space”  codes  also  have  about  twice  as  many  errors  as  the  level  codes  for  the  same 
signal-to-noise  ratio  (SNR).  If  polarity  insensitivity  is  a  major  consideration,  agreement  between 
interchange  parties  should  be  obtained  before  these  codes  are  used. 

3.1.  Some  characteristics  of  the  Bi6-L  code 

a.  Only  a  small  proportion  of  the  total  signal  energy  occurs  near  direct  current  (dc). 

b.  The  maximum  time  between  transitions  is  a  1-bit  period. 
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c.  The  symbols  for  one  and  zero  are  antipodal,  meaning  that  the  symbols  are  exact  opposites 
of  each  other.  Therefore,  the  bit  error  probability  versus  SNR  performance  is  optimum. 

d.  The  Bi(j)-L  can  be  decoded  using  existing  bit  synchronizers. 

e.  The  Bi(j)-L  is  less  sensitive  to  maladjustments  of  bias  and  reproducer  equalizers  than  most 
other  codes. 

f.  The  Bi(j)-L  performs  well  at  low  tape  speeds  and  low  bit  rates. 

The  most  unfavorable  characteristic  of  the  Bi(j)-L  code  is  that  it  requires  approximately 
twice  the  bandwidth  of  NRZ.  Consequently,  the  maximum  bit  packing  density  that  can  be 
recorded  on  magnetic  tape  is  relatively  low. 

3.2.  Favorable  characteristics  of  the  RNRZ-L  code 

a.  The  RNRZ-L  requires  approximately  one-half  the  bandwidth  of  Bi(j)-L. 

b.  The  symbols  for  one  and  zero  are  antipodal;  therefore,  the  bit  error  probability  versus 
SNR  performance  is  optimum. 

c.  The  RNRZ-L  decoder  is  self-synchronizing. 

d.  The  RNRZ-L  data  can  be  bit  synchronized  and  signal  conditioned  using  existing  bit 
synchronizers  with  the  input  code  selector  set  to  NRZ-L. 

e.  The  RNRZ-L  code  is  easily  generated  and  decoded. 

f.  The  RNRZ-L  data  can  be  easily  decoded  in  the  reverse  mode  of  tape  playback. 

g.  The  RNRZ-L  data  are  bit  detected  and  decoded  using  a  clock  at  the  bit  rate.  Therefore, 
the  phase  margin  is  much  larger  than  that  of  codes  that  require  a  clock  at  twice  the  bit  rate 
for  bit  detection. 

h.  The  RNRZ-L  code  does  not  require  overhead  bits. 

3.3.  Unfavorable  characteristics  of  the  RNRZ-L  code 

a.  Long  runs  of  bits  without  a  transition  are  possible,  although  the  probability  of  occurrence 
is  low,  and  the  maximum  run  length  can  be  limited  by  providing  transitions  in  each  data 
word. 

b.  Each  isolated  bit  error  that  occurs  after  the  data  has  been  randomized  causes  three  bit 
errors  in  the  derandomized  output  data. 

c.  The  decoder  requires  15  consecutive  error- free  bits  to  establish  and  reestablish  error- free 
operation. 

d.  The  RNRZ-L  bit  stream  can  have  large  low  frequency  content.  Consequently, 
reproducing  data  at  tape  speeds  which  produce  pulse  code  modulation  (PCM)  bit  rates 
less  than  200  kilobits  per  second  (kb/s)  is  not  recommended  unless  a  bit  synchronizer 
with  specially  designed  dc  and  low  frequency  restoration  circuitry  is  available. 
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3.4.  Randomizer  for  RNRZ-L 

The  randomizer  is  implemented  with  a  network  of  shift  registers  and  modulo-2  adders 
(exclusive-OR  gates).  The  RNRZ-L  bit  stream  is  generated  by  adding  (modulo-2)  the 
reconstructed  NRZ-L  PCM  data  to  the  modulo-2  sum  of  the  outputs  of  the  14th  and  15th  stages 
of  a  shift  register.  The  output  RNRZ-L  stream  is  also  the  input  to  the  shift  register  (see  Figure 
A.2-2). 


D 


Boolean  Expression: 

D  =  A0  B  0  C 
Figure  A.2-2.  Randomizer  block  diagram 

The  properties  of  an  RNRZ-L  bit  stream  are  similar  to  the  properties  of  a  pseudo-random 
sequence.  A  15-stage  RNRZ-L  encoder  will  generate  a  maximal  length  pseudo-random 
sequence  of  2*^-1  (32,767)  bits  if  the  input  data  consists  only  of  zeros  and  there  is  at  least  a 
single  one  in  the  shift  register.  A  maximal  length  pseudo-random  sequence  is  also  generated 
when  the  input  data  consists  only  of  ones  and  the  shift  register  contains  at  least  a  single  zero; 
however,  if  the  shift  register  contains  all  zeros  at  the  moment  that  the  input  bit  stream  is  all  zeros, 
the  RNRZ-L  output  bit  stream  will  also  be  all  zeros.  The  converse  is  also  true,  meaning  that 
when  the  shift  register  is  filled  with  ones  and  the  input  bit  stream  is  all  ones,  the  RNRZ-L  output 
bit  stream  will  also  be  all  ones.  In  these  two  cases,  the  contents  of  the  shift  register  does  not 
change  and  the  output  data  is  not  randomized;  however,  the  randomizer  is  not  permanently 
locked-up  in  this  state  because  a  change  in  the  input  data  will  again  produce  a  randomized 
output.  In  general,  if  the  input  bit  stream  contains  runs  of  X  bits  without  a  transition  with  a 
probability  of  occurrence  of  p(X),  the  output  will  contain  runs  having  a  length  of  up  to  (X-i-15) 
bits  with  a  probability  equal  to  (2"^^  •  p(X)).  Therefore,  the  output  can  contain  long  runs  of  bits 
without  a  transition,  but  the  probability  of  occurrence  is  low. 

The  RNRZ-L  bit  stream  is  decoded  (derandomized)  by  adding  (modulo-2)  the 
reconstructed  RNRZ-L  bit  stream  to  the  modulo-2  sum  of  the  outputs  of  the  14th  and  15th  stages 
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of  the  shift  register.  The  reconstructed  RNRZ-L  bit  stream  is  the  input  to  the  shift  register  (see 
Figure  A.2-3).  The  RNRZ-L  data  that  is  reproduced  using  the  reverse  playback  mode  of 
operation  is  decoded  by  adding  (modulo-2)  the  reconstructed  RNRZ-L  bit  stream  to  the  modulo- 
2  sum  of  the  outputs  of  the  1st  and  15th  stages  of  the  shift  register.  The  net  effect  is  that  the 
decoding  shift  register  runs  “backwards”  with  respect  to  the  randomizing  shift  register. 


Bit  Rate  Clock  Input 


A* 

- >.  Decoded  Data 

Output  (NUZ-L) 

Boolean  Expression: 

W'ith  input  data  A  into  randomizer, 

Error-Free  RNRZ-L  Data.  D  =  A  ©  B  ©  C  (see  Figure  D-2) 

A‘=D©B©C  =  A  ©B©C©B©C 

=  A©B©B©  C©C  But  B  ©  B  =  0 

C  ©  C  =  0 

Therefore: 

A‘=A©0©0  =  A 

Figure  A.2-3.  Randomized  NRZ-L  decoder  block  diagram 
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Although  the  RNRZ-L  decoder  is  self-synchronizing,  15  consecutive  error-free  bits  must 
be  loaded  into  the  shift  register  before  the  output  data  will  be  valid.  A  bit  slip  will  cause  the 
decoder  to  lose  synchronization,  and  15  consecutive  error- free  data  bits  must  again  be  loaded 
into  the  shift  register  before  the  output  data  is  valid.  The  decoded  output  data,  although  correct, 
will  contain  the  bit  slip  causing  a  shift  in  the  data  with  respect  to  the  frame  synchronization 
pattern.  Therefore,  frame  synchronization  must  be  reacquired  before  the  output  provides 
meaningful  data. 

The  RNRZ-L  decoding  system  has  an  error  multiplication  factor  of  3  for  isolated  bit 
errors  (separated  from  adjacent  bit  errors  by  at  least  15  bits).  An  isolated  bit  error  introduced 
after  randomization  will  produce  3  errors  in  the  output  data;  the  original  bit  in  error,  plus  two 
additional  errors  14  and  15  bits  later.  In  addition,  a  burst  of  errors  occurring  after  the  data  has 
been  randomized  will  produce  a  burst  of  errors  in  the  derandomized  output.  The  number  of 
errors  in  the  output  depends  on  the  distribution  of  errors  in  the  burst  and  can  be  greater  than, 
equal  to,  or  less  than  the  number  of  errors  in  the  input  to  the  derandomizer;  however,  the 
derandomization  process  always  increases  the  number  of  bits  between  the  first  and  last  error  in 
the  burst  by  15.  Errors  introduced  prior  to  randomization  are  not  affected  by  either  the 
randomizer  or  the  derandomizer.  The  reverse  decoder  has  the  same  bit  error  properties  as  the 
forward  decoder. 

Input  data  containing  frequent  long  runs  of  bits  without  transitions  creates  potential  dc 
and  low  frequency  restoration  problems  in  PCM  bit  synchronizers  because  of  the  low  frequency 
cutoff  of  direct  recorder  and  reproducer  systems.  The  restoration  problem  can  be  minimized  by 
reproducing  the  data  at  tape  speeds  that  produce  a  bit  rate  for  which  the  maximum  time  between 
transitions  is  less  than  100  microseconds.  Additional  methods  of  minimizing  these  effects 
include  selecting  bit  synchronizers  containing  special  dc  and  low  frequency  restoration  circuitry 
or  recording  data  using  Bi(t)-L  code. 

The  power  spectra  of  the  RNRZ-L  and  Bi(j)-L  codes  are  shown  below  in  Figure  A. 2-4. 
The  power  spectral  density  of  RNRZ-L  is  concentrated  at  frequencies  that  are  less  than  one-half 
the  bit  rate.  The  power  spectral  density  of  Bi(j)-L  is  concentrated  at  frequencies  in  a  region 
around  0.75  times  the  bit  rate.  The  concentration  of  energy  in  the  low-frequency  region  (when 
using  the  RNRZ-L  code)  has  the  effect  of  reducing  the  SNR  as  well  as  creating  baseline  wander, 
which  the  bit  synchronizer  must  follow.  Therefore,  reproducing  data  at  tape  speeds  which 
produce  PCM  bit  rates  of  less  than  200  kb/s  is  not  recommended  when  using  RNRZ-L  unless  a 
bit  synchronizer  with  specially  designed  dc  and  low  frequency  restoration  circuitry  is  available. 
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NORMALIZED  FREQUENCY  (BIT  RATE  =  1) 


Figure  A. 2-4.  Random  PCM  power  spectra 


Alignment  of  the  reproducer  system  is  very  important  to  reproducing  high  quality  PCM 
data  (i.e.  data  with  the  lowest  possible  bit  error  probability).  A  PCM  signature  using  the 
standard  2047-bit  pseudo-random  pattern,  recorded  on  the  leader  or  the  trailer  tape,  provides  a 
good  method  for  reproducer  alignment.  When  a  pseudo-random  bit  error  detection  system  is  not 
available  or  when  a  PCM  signature  signal  is  not  recorded,  the  recommended  procedure  for 
reproducer  alignment  involves  the  use  of  the  eye  pattern  technique.  The  eye  pattern  is  the  result 
of  superpositioning  the  zeros  and  ones  in  the  PCM  bit  stream.  The  eye  pattern  is  displayed  on  an 
oscilloscope  by  inserting  the  raw  reproduced  bit  stream  into  the  vertical  input  and  the 
reconstructed  bit-rate  clock  into  the  external  synchronization  input  of  the  oscilloscope.  The 
reproducer  head  azimuth,  amplitude  equalizers,  and  phase  equalizers  are  then  adjusted  to 
produce  the  eye  pattern  with  the  maximum  height  and  width  opening. 

Sample  eye  patterns  are  shown  in  Figure  A. 2-5  and  Figure  A.2-6.  Figure  A. 2-5  shows  a 
Bi(j)-L  eye  pattern  at  a  recorded  bit  packing  density  of  15  kilobits  per  inch  (kb/in)  (450  kb/s  at  30 
inches  per  second  [in/s]).  Figure  A.2-6  shows  an  RNRZ-L  eye  pattern  at  a  recorded  bit  packing 
density  of  25  kb/in  (750  kb/s  at  30  in/s). 
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Figure  A. 2-5.  Bi(j)-L  at  bit  packing  density  of  15  kb/in 


I  I  ■'  I  }  - 

Figure  A. 2-6.  RNRZ-L  at  bit  packing  density  of  25  kb/in 


4.  Head  Parameters 

The  following  describes  the  head  parameters. 

4.1.  Gap  Scatter 

Refer  to  the  definitions  in  Section  6.2  of  106-11  Chapter  6.  Gap  scatter  contains 
components  of  azimuth  misalignment  and  deviations  from  the  average  line  defining  the  azimuth. 
Since  both  components  affect  data  simultaneity  from  record  to  reproduce,  the  gap  scatter 
measurement  is  the  inclusive  distance  containing  the  combined  errors.  Because  azimuth 
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adjustment  affects  the  output  of  wide-band  systems,  a  5.08-pm  (0.0002-in.)  gap  scatter  is 
allowed  for  such  recorders  and  reproducers.  A  2.54-pm  (0.0001-in.)  gap  scatter  is  recommended 
for  fixed-head  systems  (see  Figure  A. 2- 11). 

4.2.  Head  Polarity 

The  requirement  that  a  positive  pulse  at  a  record  amplifier  input  generate  a  south-north- 
north-south  magnetic  sequence  and  that  a  south-north-north-south  magnetic  sequence  on  tape 
produce  a  positive  pulse  at  the  reproduce  amplifier  output,  still  leaves  two  interdependent 
parameters  unspecified.  These  parameters  are  (1)  polarity  inversion  or  non-inversion  in  record 
and  playback  amplifiers  and  (2)  record  or  playback  head  winding  sense.  For  the  purpose  of  head 
replacement,  it  is  necessary  that  these  parameters  be  determined  by  the  user  so  that  an 
unsuspected  polarity  inversion,  on  tape  or  off  tape,  will  not  occur  after  heads  are  replaced. 

5.  Record  Level 

The  standard  record  level  is  established  as  the  input  level  of  a  sinusoidal  signal  set  at  the 
record  level  set  frequency  which,  when  recorded,  produces  a  signal  containing  1  percent  third 
harmonic  distortion  at  the  output  of  a  properly  terminated  reproduce  amplifier  (see  Subparagraph 
5. 3. 8. 2  of  Volume  III,  RCC  Document  118^).  A  one  percent  harmonic  distortion  content  is 
achieved  when  the  level  of  the  third  harmonic  component  of  the  record  level  set  frequency  is  40 
+1  dB  below  the  level  of  a  sinusoidal  signal  of  0.3  upper  band  edge  (UBE)  which  is  recorded  at 
the  standard  record  level.  Standard  test  and  operating  practice  is  to  record  and  reproduce 
sinusoidal  signals  at  0.1  and  0.3  UBE  and  adjust  the  equalizers  as  necessary  to  establish  the 
reproduced  output  at  0.3  UBE  to  within  +1.0  dB  of  the  output  at  0.1  UBE.  Then  a  1-volt  (V) 
root  mean  square  (rms)  signal  at  the  record  level  set  frequency  is  applied  to  the  record  amplifier 
input  and  the  record  and  reproduce  level  controls  are  adjusted  until  the  reproduced  output 
contains  1  percent  third  harmonic  distortion  at  a  level  of  1  V  rms. 

The  optimum  level  for  recording  data  will  seldom  be  equal  to  the  standard  record  level. 
Signals  having  noise-like  spectral  distribution  such  as  baseband  multiplexes  of  frequency 
modulation  (EM)  subcarriers  contain  high  crest  factors  so  that  it  may  be  necessary  (as 
determined  in  Subparagraph  1.1,  Volume  IV,  RCC  Document  118^)  to  record  at  levels  below  the 
standard  record  level.  On  the  other  hand,  for  predetection  and  HDDR  recording,  signals  may 
have  to  be  recorded  above  the  standard  record  level  to  give  optimum  performance  in  the  data 
system. 


6.  Tape  Crossplay  Considerations 

Eigure  A. 2-7  illustrates  the  typical  departure  from  optimum  frequency  response  that  may 
result  when  crossplaying  wide-band  tapes  that  were  recorded  with  heads  employing  different 
record-head  gap  lengths.  Eine  AA  is  the  idealized  output- versus-frequency  plot  of  a  machine 


'  Range  Commanders  Council.  .  “Test  Methods  for  Recorder  and  Reproducer  Systems  and  Magnetic  Tape.” 
Volume  III.  RCC  118-99.  May  be  superseded  by  update.  Retrieved  3  June  2015.  Available  at 
http://vv'vv'w.wsmr.armv.mil/RCCsite/Documents/l  18-99  Vol  3- 
Test  Methods  for  Recorder  and  Reproducer  Systems  and  Magnetic  Tape/. 

^  Range  Commanders  Council.  “Test  Methods  for  Telemetry  Systems  and  Subsystems.”  RCC  118  Volume  IV. 
May  be  superseded  by  update.  Retrieved  3  June  2015.  Available  at 

http://www.vv'smr.armv.mil/RCCsite/Documents/l  18-79  Vol  4-Test  Methods  for  Data  Multiplex  Equipment/. 


A.2-13 


Telemetry  Standards,  IRIG  Standard  106-17  Annex  A. 2,  May  2017 


with  record  bias  and  record  level,  set  upper  IRIG  standards,  using  a  3.05-pm  (120-microinch) 
record-head  gap  length  and  a  1 .02-pm  (40-microinch)  reproduce-head  gap  length.  Lines  BB  and 
CC  represent  the  output  response  curves  of  the  same  tapes  recorded  on  machines  with  5.08-pm 
(200-microinch)  and  1.27-pm  (50-microinch)  record-head  gap  lengths.  Each  of  these  recorders 
was  set  up  individually  per  IRIG  requirements.  The  tapes  were  then  reproduced  on  the  machine 
having  a  1. 02-pm  (40-microinch)  reproduce-head  gap  length  without  readjusting  its  reproduce 
equalization. 


The  output  curves  have  been  normalized  to  0  dB  at  the  0. 1  UBE  frequency  for  the 
purpose  of  clarity.  The  normalized  curves  may  be  expected  to  exhibit  a  +2.0  dB  variance  in 
relative  output  over  the  passband.  The  tape  recorded  with  the  shortest  head  segment  gap  length 
will  provide  the  greatest  relative  output  at  the  UBE. 

While  the  examples  shown  are  from  older  equipment  with  record  gap  lengths  outside  the 
limits  recommended  in  Subsection  1.1.4,  they  illustrate  the  importance  of  the  record  gap  length 
in  tape  interchange  applications. 

7.  Standard  Tape  Signature  Procedures 

The  following  describes  the  recording  and  playback  procedures  for  the  PCM  signature 
and  the  swept-frequency  signature. 

7.1.  PCM  Signature  Recording  Procedure 

Test  equipment  should  be  configured  as  described  in  Paragraph  2.1,  Volume  IV,  RCC 
Document  118.  The  configuration  should  simulate  the  operational  link  as  closely  as  possible  to 
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include  the  same  radio  frequency,  deviation,  bit  rate,  code  type,  predetection  frequency,  receiver 
bandwidth,  and  recorder  speed.  The  following  is  the  PCM  signature  recording  procedure. 

a.  While  recording  the  pseudo-random  data  at  standard  record  level,  adjust  the  signal 
generator  output  level  until  approximately  one  error  per  10^  bits  is  obtained  on  the  error 
counter. 

b.  Record  30  seconds  of  the  pseudo-random  data  at  the  beginning  or  end  of  the  tape  for  each 
data  track.  A  separate  30-second  tape  signature  is  recommended  for  each  different  data 
format. 

c.  The  content,  track  assignments,  and  location  on  the  tape  leader  and  trailer  of  signature 
signals  should  be  noted  on  the  tape  label. 

7.2.  PCM  Signature  Playback  Procedure 

The  following  steps  explain  the  playback  procedure. 

a.  Optimize  playback  equipment  such  as  receiver  tuning  and  bit  synchronizer  setup  for  data 
being  reproduced. 

b.  Reproduce  the  tape  signature  and  observe  the  error  rate  on  the  error  counter. 

c.  Optimize  head  azimuth  for  maximum  signal  output  and  minimum  errors. 

d.  Initiate  corrective  action  if  more  than  one  error  per  10"^  bits  is  obtained. 

e.  Repeat  for  each  data  track. 

7.3.  Swept-Frequency  Signature  Recording  Procedure 

The  following  steps  describe  the  recording  procedure  for  the  swept-frequency  signature. 

a.  Patch  a  sweep-frequency  oscillator  output  to  all  prime  data  tracks  up  to  6  on  7-track 
recorders  or  up  to  13  on  14-track  recorders.  As  a  minimum,  patch  the  sweep  oscillator  to 
one  odd  and  one  even  track. 

b.  Connect  the  sync  output  of  the  sweep  oscillator  to  a  track  not  used  for  sweep  signals, 
preferably  an  outside  track. 

c.  Record  the  signature  signals  for  a  minimum  of  30  seconds  at  standard  record  level. 


NOTE^ 

Record  levels  may  be  either  pre-adjusted  or  quickly  adjusted  in 

all  tracks  during  the  first  few  seconds  of  the  signature 

r 

recording. 

d.  Note  the  content,  track  assignments,  and  location  on  the  leader  or  trailer  tape  of  signature 
signals  on  the  tape  label. 

7.4.  Swept-Frequency  Signature  Playback  Procedure 

The  following  steps  define  the  steps  for  the  playback  procedure, 
a.  Connect  the  sync  track  output  of  the  reproducer  to  the  sync  input  of  the  scope. 
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b.  Select  an  odd-numbered  sweep-signal  track  and  connect  the  output  of  the  reproducer  to 
the  vertical  input  of  the  scope.  Playback  the  sweep  signal  and  adjust  the  scope  gain  for 
an  amplitude  of  approximately  +10  minor  vertical  divisions  about  the  center  baseline. 
Adjust  the  odd-track  azimuth  for  maximum  amplitude  of  the  highest  frequency  segment 
(extreme  right  of  the  sweep  pattern). 

c.  Observe  amplitude  variations  through  the  sweep  pattern  and  adjust  the  equalization,  if 
necessary,  to  maintain  the  amplitude  within  the  required  tolerance  over  the  required 
frequency  range. 


NOTE^ 

A  decrease  of  sweep  signal  amplitude  to  about  0.7 

r 

represents  a  3-dB  loss. 

d.  Repeat  the  playback  procedure  in  the  previous  two  steps  for  azimuth  and  equalization 
adjustments  of  an  even-numbered  tape  track. 

e.  Repeat  the  procedure  in  step  c  for  equalization  only  of  other  selected  prime  data  tracks,  as 
required. 

8.  Equipment  Required  for  Swept-Frequency  Procedures 

Equipment  required  at  the  recording  site  consists  of  a  sweep-frequency  oscillator  having 
a  constant  amplitude  sweep  range  of  approximately  400  hertz  (Hz)  through  4.4  MHz  with 
frequency  markers  at  62.5,  125,  250,  and  500  kilohertz  (kHz)  and  1.0,  2.0,  and  4.0  MHz.  The 
sweep  range  to  4.4  MHz  may  be  used  for  all  tape  speeds  because  the  bandwidth  of  the  recorder 
and  reproducer  will  attenuate  those  signal  frequencies  beyond  its  range.  The  sweep  rate  should 
be  approximately  25  Hz.  Care  should  be  exercised  in  the  installation  of  the  sweep  generator  to 
ensure  a  flat  response  of  the  sweep  signal  at  the  input  terminals  of  the  recorder.  Appropriate 
line-driver  amplifiers  may  be  required  for  long  cable  runs  or  the  low  impedance  of  paralleled 
inputs. 

A  stepped-frequency  oscillator  could  be  substituted  for  the  sweep-frequency  generator  at 
the  recording  location.  Recommended  oscillator  wavelengths  at  the  mission  tape  speed  are 
7.62  mm  (300  mils),  3.81  mm  (150  mils),  0.254  mm  (10  mils),  0.0254  mm  (1  mil),  0.0127  mm 
(0.5  mil),  0.0064  mm  (0.25  mil),  0.0032  mm  (0.125  mil),  0.0025  mm  (0.1  mil),  0.0020  mm 
(0.08  mil),  and  0.0015  mm  (0.06  mil). 

Equipment  required  at  the  playback  site  consists  of  an  ordinary  oscilloscope  having  a  flat 
frequency  response  from  400  Hz  through  4.4  MHz. 

9.  Fixed-Frequency  Plus  White  Noise  Procedure 

The  signature  used  in  this  method  is  the  same  for  all  applications.  For  direct  recording  of 
subcarrier  multiplexes,  only  static  nonlinearity  (nonlinearity  which  is  independent  of  frequency) 
is  important  for  crosstalk  control.  Subparagraph  17.2  provides  a  reference  level  for  static 
nonlinearity.  All  formats  of  data  recording  are  sensitive  to  SNR.  Predetection  recording  and 
HDDR  are  sensitive  to  equalization.  The  following  signature  procedure  satisfies  all  the  above 
requirements. 
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a.  Record  a  sine-wave  frequency  of  0.1  UBE  (see  Table  A.2-6)  with  the  following 
amplitudes. 

(1)  Equal  to  the  standard  record  level  for  direct  recording  of  subcarrier  multiplexes  and 
HDDR  (see  Subparagraph  17.2). 

(2)  Equal  to  the  carrier  amplitude  to  be  recorded  for  pre-detection  recording  of 
PCM/EM,  PCM/PM,  PM/PM,  and  pulse  amplitude  modulation/PM. 

b.  Record  flat  band-limited  white  noise  of  amplitude  0.7  of  the  true  rms  value  of  the  0-dB 
standard  record  level  as  described  in  Subparagraph  17.2.  Noise  must  be  limited  by  a  low- 
pass  filter  just  above  the  UBE. 

c.  Record  with  zero  input  (input  terminated  in  75  ohms).  The  three  record  steps  previously 
described  can  consist  of  10  seconds  each.  The  spectra  can  be  obtained  with  three 
manually  initiated  sweeps  of  less  than  a  second  each,  because  no  great  frequency 
resolution  is  required.  All  of  the  spectrum  analyzer  parameters  can  be  standardized  and 
set  in  (inputted)  prior  to  running  the  mission  tape. 


10.  Signature  Playback  and  Analysis 

Before  analyzing  the  signature,  the  reproducer  azimuth  should  be  adjusted.  With  the 
short  signature,  it  is  probably  more  convenient  to  use  the  data  part  of  the  recording  for  this 
purpose.  If  predetection  recording  is  used,  the  azimuth  can  be  adjusted  to  maximize  the  output 
as  observed  on  the  spectrum  analyzer  or  on  a  voltmeter  connected  to  the  output.  If  baseband 
recording  is  used,  the  azimuth  can  be  adjusted  to  maximize  the  spectrum  at  the  upper  end  of  the 
band.  A  spectrum  analyzer  should  be  used  to  reproduce,  store,  and  photograph  the  spectra 
obtained  from  steps  a,  b,  and  c  in  Section  9.  The  spectrum  analyzer  input  level  of  zero  should  be 
stored  and  photographed. 

It  is  evident  that  any  maladjustment  of  the  recorder  and  reproducer  or  magnetization  of 
the  heads  will  result  in  the  decrease  of  SNR  across  the  band  and  will  be  seen  from  the  stored 
spectra  or  photograph. 

By  having  a  photograph  of  the  spectra,  amplitude  equalization  can  be  accomplished 
without  shuttling  the  mission  tape  as  follows. 

a.  Use  an  auxiliary  tape  (not  the  mission  tape,  but  preferably  the  same  type  tape).  With  a 
white-noise  input  signal  band  limited,  adjust  the  amplitude  equalization  of  the  recorder 
and  reproducer  at  the  tape  dubbing  or  data  reduction  site  and  photograph  the  output 
spectrum  (see  Section  9). 

b.  Compare  this  photo  with  the  photo  made  from  the  signature.  Note  the  difference  at 
several  points  across  the  band. 

c.  Using  the  auxiliary  tape,  adjust  the  amplitude  equalization  to  compensate  for  the 
differences  noted. 

d.  Recheck  with  the  mission  tape  to  verify  that  the  desired  amplitude  equalization  has  been 
achieved. 
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If  the  phase  equalization  is  to  be  checked,  a  square  wave  signal  can  be  added  to  the 
signature  in  accordance  with  the  manufacturer’s  specification  (see  Volume  III,  RCC  Document 
118).  The  same  procedure  that  is  recommended  for  amplitude  equalization  can  be  used,  except 
the  procedure  is  based  on  oscillograms. 

11.  Recording  and  Playback  Alignment  Procedures 

When  using  standard  preamble  (or  postamble),  see  Section  2J_. 

11.1.  Recording  of  Preamble  for  Direct  Electronics  Alignment. 

a.  Patch  a  square  wave  generator  output  set  to  1/11  band  edge  to  all  tracks  having  direct 
electronics  or  initiate  procedure  for  recording  internally  generated  1/1 1  band  edge  square 
wave  according  to  manufacturer’s  instructions. 

b.  If  the  preamble  will  be  used  for  a  manual  adjustment,  record  for  a  minimum  of  30 
seconds  at  the  standard  record  level  and  tape  speed  to  be  used  for  data  recording. 

c.  If  the  preamble  will  be  used  only  for  automatic  alignment,  record  at  the  standard  record 
level  and  tape  speed  to  be  used  for  data  recording  for  a  sufficient  time  as  specified  by  the 
manufacturer  of  the  playback  recorder  reproducer  or  as  agreed  by  the  interchange  parties. 

11.2.  Playback  of  Preamble  for  Direct  Electronics  Alignment. 

For  systems  so  equipped,  initiate  automatic  alignment  procedure  per  manufacturer’s 
instructions.  The  procedure  for  manual  adjustment  is  described  in  the  following  steps. 

a.  Display  fundamental  and  odd  harmonics  of  the  square  wave  (third  through  eleventh)  of 
selected  odd  numbered  direct  track  near  center  of  head  stack  on  the  spectrum  analyzer. 
Adjust  azimuth  by  peaking  output  amplitude  of  the  third  through  eleventh  harmonic. 
Final  adjustment  should  peak  the  eleventh  harmonic. 

b.  Repeat  step  a  for  even  numbered  direct  track.  (Only  one  track  is  necessary  for  a  double¬ 
density,  14-track,  in-line  system.) 

c.  Observe  frequency  response  across  the  band  pass  on  selected  track  and  correct  if 
necessary.  For  a  flat  response,  the  third  harmonic  will  be  1/3  of  the  amplitude  of  the 
fundamental,  fifth  harmonic  1/5  the  amplitude,  and  so  on.  A  convenient  method  is  to 
compare  the  recorder/reproducer  output  with  that  of  a  square  wave  generator  patched 
directly  to  the  spectrum  analyzer. 


NOTE^ 

An  alternate,  but  less  accurate,  method  is  to  optimize  the 

r 

square  wave  as  displayed  on  an  oscilloscope  rather  than  a 

r 

spectrum  analyzer. 

d.  Repeat  step  c  for  each  direct  track. 

e.  Display  square  wave  on  an  oscilloscope.  Adjust  phase  for  best  square  wave  response  as 
shown  in  Figure  A.2-8. 

f.  Repeat  step  e  for  each  direct  track. 
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11.3.  Recording  of  Preamble  for  FM  Electronics  Alignment 

If  available,  initiate  the  procedure  for  recording  internally  generated  1/1 1  band  edge 
square  wave  and  +1.414  Vdc  per  manufacturer's  instructions.  Otherwise,  patch  a  square  wave 
generator  output  to  all  tracks  having  FM  electronics.  A  near  dc  signal  may  be  obtained  by 
setting  the  square  wave  generator  to  0.05  Hz  and  +1.414  V  or  by  using  a  separate  dc  source. 

a.  If  the  preamble  will  be  used  for  manual  alignment,  record  at  least  one  cycle  of  the  0.05 
Hz  square  wave  at  +1.414  V  or  a  positive  and  negative  1.414  Vdc  for  a  minimum  of  10 
seconds  each  at  the  tape  speed  to  be  used  for  data  recording.  Next,  record  a  1/1 1  band 
edge  square  wave  for  a  minimum  of  20  seconds. 

b.  If  the  preamble  will  be  used  only  for  automatic  alignment,  record  the  above  sequence  for 
a  sufficient  time  as  specified  by  the  manufacturer  of  the  playback  recorder/reproducer  or 
as  agreed  by  the  interchange  parties. 

11.4.  Playback  of  Preamble  for  FM  Electronics  Alignment 

For  systems  so  equipped,  initiate  automatic  alignment  procedure  per  manufacturer’s 
instructions.  The  procedure  for  manual  adjustment  is  described  in  the  next  steps. 

a.  Check  and  adjust  for  0-V  output  at  center  frequency  per  RCC  Document  118,  Test 
Methods  for  Telemetry  Systems  and  Subsystems,  Volume  III,  Test  Methods  for 
Recorder/Reproducer  Systems  and  Magnetic  Tape. 

b.  Use  dc  voltmeter  to  verify  a  full  positive  and  negative  output  voltage  on  the  selected 
track  and  correct  if  necessary. 

c.  Display  fundamental  and  odd  harmonics  of  the  square  wave  (third  through  eleventh)  on 
the  spectrum  analyzer. 

d.  Observe  frequency  response  per  step  c  in  Subsection  11.2. 

e.  Repeat  steps  a  through  c  for  each  FM  track. 
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12.  General  Considerations  for  Longitudinal  Recording 

Standard  recording  techniques,  tape  speeds,  and  tape  configurations  are  required  to 
provide  maximum  interchange  of  recorded  telemetry  magnetic  tapes  between  the  test  ranges. 

Any  one  of  the  following  methods  of  information  storage  or  any  compatible  combination  may  be 
used  simultaneously:  direct  recording,  predetection  recording,  FM  recording,  or  PCM  recording. 
Double-density  recording  may  be  used  when  the  length  of  recording  time  is  critical;  however,  it 
must  be  used  realizing  that  performance  parameters  such  as  SNR,  crosstalk,  and  dropouts  may  be 
degraded  (see  Section  2). 

12.1.  Tape  Speeds 

The  standard  tape  speeds  for  instrumentation  magnetic  tape  recorders  are  shown  in  Table 

A.2-4. 

12.2.  Tape  Width 

The  standard  nominal  tape  width  is  25.4  mm  (1  in.)  (see  Table  A. 2-17). 

12.3.  Record  and  Reproduce  Bandwidths 

For  the  purpose  of  these  standards,  two  system  bandwidth  classes  are  designated:  wide 
band  and  double  density  (see  Table  A.2-4).  Interchange  of  tapes  between  the  bandwidth  classes 
is  NOT  recommended. 

13.  Recorded  Tape  Format 

The  parameters  related  to  recorded  tape  format  and  record  and  reproduce  head 
configurations  determine  compatibility  between  systems  that  are  vital  to  interchangeability 
(crossplay)  of  recorded  magnetic  tapes.  Refer  to  the  definitions  in  Section  6.2  of  106-11  Chapter 
6,  Figure  A. 2-9,  Figure  A. 2-10,  and  Figure  A.2-1 1.  Refer  also  to  Table  A. 2-5,  Table  A. 2-6, 

Table  A. 2-7,  and  Figure  A. 2-12. 
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Figure  A. 2-9.  Recorded  tape  format 
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Figure  A. 2- 10.  Head  and  head  segment  mechanical  parameters 
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Figure  A.2-1 1  Record  and  reproduce  head  and  head  segment  identification  and  location  (N-track 

interlaced  system) 
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TELEMETRY  RECEIVER 


*  May  be  part  of  Bit  Sync 


PCM  -  Record  Mode 


PCM  -  Reproduce  Mode 

Figure  A.2-12.PCM  record  and  reproduce  configuration 


13.1.  Track  Width  and  Spacing 

Refer  to  Figure  A.2-1 1,  Table  A. 2-5,  Table  A.2-6,  and  Table  A. 2-7. 

13.2.  Track  Numbering 

The  tracks  on  a  tape  are  numbered  consecutively  from  track  1  through  track  n  with  track 
1  located  nearest  the  tape  reference  edge  as  shown  in  Figure  A. 2-9. 

13.3.  Data  Spacing 

For  interlaced  formats,  the  spacing  on  tape  between  simultaneous  events  on  odd  and  even 
tracks  is  nominally  38.1  mm  (1.5  in).  See  Subparagraph  1.1.1. 
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13.4.  Head  Placement 

The  standard  technique  for  wide  band  and  28-track  double  density  is  to  interlace  the 
heads,  both  the  record  and  the  reproduce,  and  to  provide  alternate  tracks  in  separate  heads.  Thus, 
to  record  on  all  tracks  of  a  standard  width  tape,  two  interlaced  record  heads  are  used.  To 
reproduce  all  tracks  of  a  standard  width  tape,  two  interlaced  reproduce  heads  are  used.  For  14- 
track  double  density,  the  standard  technique  uses  one  in-line  record  head  and  one  in-line 
reproduce  head. 

1.1.1  Head  Placement,  Interlaced 

Two  heads  comprise  the  record-head  pair  or  the  reproduce-head  pair.  Mounting  of  either 
head  pair  is  done  in  such  a  manner  that  the  center  lines  drawn  through  the  head  gaps  are  parallel 
and  spaced  38.10  mm  +0.05  (1.500  in.  +0.002)  apart,  as  shown  in  Table  A. 2-5  and  Table  A. 2-7, 
for  systems  that  include  head  azimuth  adjustment.  The  dimension  between  gap  centerlines 
includes  the  maximum  azimuth  adjustment  required  to  meet  system  performance  requirements. 
For  systems  with  fixed  heads  (i.e.,  heads  without  an  azimuth  adjustment),  the  spacing  between 
gap  centerlines  shall  be  38.10  mm  +0.03  (1.500  in.  +0.001)  (see  Figure  A.2-10). 

1.1.2  Head  Identification  and  Location 

A  head  segment  is  numbered  to  correspond  to  the  track  number  that  segment  records  or 
reproduces.  Tracks  1,  3,  5,...  are  referred  to  as  the  “odd”  head  segments.  Tracks  2,  4,  6,...  are 
referred  to  as  the  even  head  segments.  For  interlaced  heads,  the  head  containing  the  odd 
numbered  segments  (odd  head)  is  the  first  head  in  a  pair  of  heads  (record  or  reproduce)  over 
which  an  element  of  tape  passes  when  moving  in  the  forward  record  or  reproduce  direction  (see 
Figure  6-2  of  106-11  Chapter  6). 

1.1.3  In-Line  Head  Placement 

An  in-line  head  shall  occupy  the  position  of  head  number  1  in  an  interlaced  system. 

1.1.4  Head  Segment  Location 

Any  head  segment  within  a  head  shall  be  located  within  +0.05  mm  (+0.002  in.)  of  the 
nominal  (dimension  from  table  without  tolerances)  position  required  to  match  the  track  location 
as  shown  in  Figure  A.2-1 1,  Table  A.2-5,  Table  A. 2-6,  and  Table  A. 2-7. 


Table  A.2-4.  Record  and  Reproduce  Parameters 

Tape  Speed 

+3  dB  Reproduce 
Passband 
kHz(i> 

Direct  Record  Bias 
Set  Frequency 
(UBE)  kHz(2) 

Level  Set  Frequency 
10%  of  UBE,  kHz 

mm/s 

in/s 

Wide  Band 

Over 

Dias  2dB 

6096.0 

240 

0.8-4000 

4000 

400 

3048.0 

120 

0.4-2000 

2000 

200 

1524.0 

60 

0.4-1000 

1000 

100 

762.0 

30 

0.4-500 

500 

50 

381.0 

15 

0.4- 

250 

25 

190.5 

7-1/2 

0.4-5 

125 

12.5 

95.2 

3-3/4 

0.4-2.5 

62.5 

6.25 

47.6 

1-7/8 

0.4-31.25 

31.25 

3.12 
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Double  Density 

Overbias  2  dB 

3048.0 

120 

2-4000 

4000 

1524.0 

60 

2-2000 

2000 

762.0 

30 

2-1000 

1000 

381.0 

15 

2-500 

500 

190.0 

7-1/2 

1-250 

250 

25 

95.2 

3-3/4 

0.5-125 

125 

12.5 

Notes: 

1 .  Passband  response  reference  is  the  output  amplitude  of  a  sinusoidal  signal  at  the  record 
level  set  frequency  recorded  at  standard  record  level.  The  record  level  set  frequency  is  ten 
percent  of  the  upper  band  edge  frequency  (0. 1  UBE). 

2.  When  setting  record  bias  level,  a  UBE  frequency  input  signal  is  employed.  The  signal 
input  level  is  set  5  to  6  dB  below  standard  record  level  to  avoid  saturation  effects  which 
could  result  in  erroneous  bias  level  settings.  The  record  bias  current  is  adjusted  for 
maximum  reproduce  output  level  and  then  increased  until  the  output  level  decreases  by  the 
number  of  dB  indicated  in  the  table  (see  Subparagraph  5.3.8. 1  of  Volume  III,  RCC 
Document  118). 


Table  A.2-5.  Dimensions  -  Recorded  Tape  Format  - 14  Tracks 

Interlaced  on  25.4  mm  (1  inch)  Wide  Tape^^^ 

Parameters 

Millimeters 

Inches 

Track  Width 

1.397  (Min);  1.143  (Max) 

0.050  +0.005 

Track  Spacing 

1.778 

0.070 

Eixed  Head  Spacing 

38.075  (Max);  38.125  (Min) 

1.500+0.001 

Adjustable  Head  Spacing 

38.151  (Max);  38.049  (Min) 

1.500+0.002 

Edge  Margin,  Minimum 

0.279 

1.011 

Reference  Track  Eocation 

1.168  (Max);  1.067  (Min) 

0.044  +0.002 

Track  Eocation  Tolerance 

0.051  (Max);  -0.051  (Min) 

+0.002 

Location  of  Track 

Track  Number 

Millimeters 

Inches 

1  (Reference) 

0.000 

0.000 

2 

1.829  (Max);  1.727  (Min) 

0.070 

3 

3.607  (Max);  3.505  (Min) 

0.140 

4 

5.385  (Max);  5.283  (Min) 

0.210 

5 

7.163  (Max);  7.061  (Min) 

0.280 

6 

8.941  (Max);  8.839  (Min) 

0.350 

7 

10.719  (Max);  10.617  (Min) 

0.420 

8 

12.497  (Max);  2.395  (Min) 

0.490 

9 

14.275  (Max);  14.173  (Min) 

0.560 

10 

16.053  (Max);  15.951  (Min) 

0.630 

11 

17.831  (Max);  17.729  (Min) 

0.700 

12 

19.609  (Max);  19.507  (Min) 

0.770 

13 

21.387  (Max);  21.285  (Min) 

0.840 
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14 

23.165  (Max);  23.063  (Min) 

0.910 

Note  1.  Refer  to  Figure  A. 2-9. 

Table  A.2-6.  Dimensions  -  Recorded  Tape  Format  - 14  Tracks  In- 

Line  On  25.4  mm  (1  inch)  Wide  Tape^^^ 

Parameters 

Millimeters 

Inches 

Track  Width 

0.660  (Max);  0.610  (Min) 

0.25  +0.001 

Track  Spacing 

1.778 

0.070 

Edge  Margin,  Minimum*^^^ 

1.118  (Max);  0.044  (Min) 

Reference  Track  Location 

0.698  (Max);  0.622  (Min) 

0.0260+0.0015 

Track  Location  Tolerance 

0.038  (Max);  -0.038  (Min) 

+0.0015 

Location  of  n‘**  track 

Track  Number 

Millimeters 

Inches 

1  (Reference) 

0.000 

0.000 

2 

1.816  (Max);  1.740  (Min) 

0.070 

3 

3.594  (Max);  3.518  (Min) 

0.140 

4 

5.372  (Max);  5.296  (Min) 

0.210 

5 

7.150  (Max);  7.074  (Min) 

0.280 

6 

8.928  (Max);  8.852  (Min) 

0.350 

7 

10.706  (Max);  10.630  (Min) 

0.420 

8 

12.484  (Max);  12.408  (Min) 

0.490 

9 

14.262  (Max);  14.186  (Min) 

0.560 

10 

16.040  (Max);  15.964  (Min) 

0.630 

11 

17.818  (Max);  17.742  (Min) 

0.700 

12 

19.596  (Max);  19.520  (Min) 

0.770 

13 

21.374  (Max);  21.298  (Min) 

0.840 

14 

23.152  (Max);  23.076  (Min) 

0.910 

Notes: 

1 .  Refer  to  Figure  A. 2- 9. 

2.  Track  location  and  spacing  are  the  same  as  the  odd  tracks  of  the  28-track  interlaced 
format  (see  Table  A.2-7).  The  minimum  edge  margin  for  track  1  is  only  0.044  mm 
(0.009  inch). 

Table  A.2-7.  Dimensions  -  Recorded  Tape  Format  - 14  Tracks 

Interlaced  On  25.4  mm  (1  inch)  Wide  Tape^^^ 

Parameters 

Millimeters 

Inches 

Track  Width 

0.660  (Max);  0.610  (Min) 

0.25  +0.001 

Track  Spacing 

0.889 

0.035 

Fixed  Head  Spacing 

38.125  (Max);  38.075  (Min) 

1.500  +0.001 

Adjustable  Head  Spacing 

38.151  (Max);  38.049  (Min) 

1.500  +0.002 

Edge  Margin,  Minimum^^^ 

0.229 

1.009 

Reference  Track  Location 

0.699  (Max);  0.622(Min) 

0.0260  +0.0015 

A.2-26 


Telemetry  Standards,  IRIG  Standard  106-17  Annex  A. 2,  May  2017 


Track  Location  Tolerance 

0.038  (Max);  -0.038(Min) 

+0.0015 

Location  of  n‘**  Track 

Track  Number 

Millimeters 

Inches 

1  (Reference) 

0.000 

0.000 

2 

0.927  (Max);  0.851  (Min) 

0.035 

3 

1.816  (Max);  1.740  (Min) 

0.170 

4 

2.705  (Max);  2.629  (Min) 

0.105 

5 

3.594  (Max);  3.518  (Min) 

0.140 

6 

4.483  (Max);  4.407  (Min) 

0.175 

7 

5.372  (Max);  5.296  (Min) 

0.210 

8 

6.261  (Max);  6.185  (Min) 

0.245 

9 

7.150  (Max);  7.074  (Min) 

0.280 

10 

8.039  (Max);  7.963  (Min) 

0.315 

11 

8.928  (Max);  8.852  (Min) 

0.350 

12 

9.817  (Max);  9.741  (Min) 

0.385 

13 

10.706  (Max);  10.630  (Min) 

0.420 

14 

11.595  (Max);  11.519  (Min) 

0.455 

15 

12.484  (Max);  12.408  (Min) 

0.490 

16 

13.373  (Max);  13.297  (Min) 

0.525 

17 

14.262  (Max);  14.186  (Min) 

0.560 

18 

15.151  (Max);  15.075  (Min) 

0.595 

19 

16.040  (Max);  15.964  (Min) 

0.630 

20 

16.929  (Max);  16.853  (Min) 

0.665 

21 

17.818  (Max);  17.742  (Min) 

0.700 

22 

18.707  (Max);  18.631  (Min) 

0.735 

23 

19.596  (Max);  19.520  (Min) 

0.770 

24 

20.485  (Max);  20.409  (Min) 

0.805 

25 

21.374  (Max);  21.298  (Min) 

0.840 

26 

22.263  (Max);  22.187  (Min) 

0.875 

27 

23.152  (Max);  23.076  (Min) 

0.910 

28 

24.041  (Max);  23.965  (Min) 

0.945 

Notes: 

1 .  Refer  to  Figure  A. 2-9. 

2.  Track  location  and  spacing  for  the  odd  tracks  are  same  as  the  tracks  of  the  14-track 
inline  format  (see  Table  A. 2-6).  Edge  margin  for  track  1  is  only  0.229  mm  (0.009  in). 

14.  Head  and  Head  Segment  Mechanical  Parameters 

The  following  describes  the  mechanical  parameters  of  the  head  and  head  segments. 

14.1.  Gap  Scatter 

Gap  scatter  shall  be  0.005  mm  (0.0002  in.)  or  less  for  25.4  mm  (1  in.)  tape  (see  Figure 
A. 2- 11  and  Subparagraph  4.1). 
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14.2.  Head  Segment  Gap  Azimuth  Alignment 

The  head  segment  gap  azimuth  shall  be  perpendicular  to  the  head  reference  plane  to 
within  +0.29  mrad  (+1  minute  of  arc). 

14.3.  Head  Tilt 

The  plane  tangent  to  the  front  surface  of  the  head  at  the  center  line  of  the  head  segment 
gaps  shall  be  perpendicular  to  the  head  reference  plane  within  +0.29  mrad  (+1  minute  of  arc)  for 
wide -band  and  double-density  recorders  (see  Figure  A.2-11). 

14.4.  Record-Head  Segment  Gap  Parameters 

The  parameters  for  the  length  and  azimuth  alignment  are  described  in  the  following 
subparagraphs. 

14.4.1.  Record-Head  Segment  Gap  Length 

The  record  gap  length  (the  perpendicular  dimension  from  the  leading  edge  to  the  trailing 
edge  of  the  gap)  shall  be  2.16  pm  +0.5  (85  microinch  +20)  for  wide -band  recorders  and  0.89  pm 
+0.12  (35  microinch  +5)  for  double-density  recorders  (see  Figure  6-3  of  106-11  Chapter  6  and 
Section  6). 

14.4.2.  Record-Head  Stack  Gap  Azimuth  Alignment 

The  record-head  stack  azimuth  shall  be  perpendicular  to  the  head  reference  surface  to 
within  +0.29  mrad  (+1  minute  of  arc).  See  Subparagraph  1.2,  Volume  III,  RCC  Document  118 
for  suggested  test  procedure. 

14.4.3.  Reproduce-Head  Segment  Gap  Azimuth  Alignment 

The  reproduce-head  segment  azimuth  alignment  shall  match  that  of  the  record-head 
segment  as  indicated  by  reproducing  a  UBE  frequency  signal  on  a  selected  track  and  setting  the 
reproduce  head  azimuth  for  the  maximum  output.  At  this  azimuth  setting,  the  output  of  any 
other  track  in  the  reproduce  head  shall  be  within  2  dB  of  the  output  at  its  own  optimum  azimuth 
setting  (see  Subparagraph  1.3,  Volume  III,  RCC  Document  118). 

15.  Head  Polarity 

Also  refer  to  Chapter  1,  Volume  III,  RCC  Document  118  and  Subparagraph  4^  herein. 

15.1.  Record-Head  Segment 

Each  record-head  winding  shall  be  connected  to  its  respective  amplifier  in  such  a  manner 
that  a  positive  going  pulse  referenced  to  system  ground  at  the  record  amplifier  input  will  result  in 
the  generation  of  a  specific  magnetic  pattern  on  a  segment  of  tape  passing  the  record  head  in  the 
normal  direction  of  tape  motion.  The  resulting  magnetic  pattern  shall  consist  of  a  polarity 
sequence  of  south-north-north-south. 

15.2.  Reproduce- Head  Segment 

Each  reproduce-head  segment  winding  shall  be  connected  to  its  respective  amplifier  in 
such  a  manner  that  an  area  of  a  tape  track  exhibiting  a  south-north-north-south  magnetic  pattern 
will  produce  a  positive  going  pulse  with  respect  to  system  ground  at  the  output  of  the  reproducer 
amplifier. 
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16.  Magnetic  Tape  and  Reel  Characteristics 

It  is  recommended  that  all  recorder  and  reproducer  systems  at  a  particular  test  range  be 
calibrated  for  operational  use  against  a  reference  tape  of  the  type  used  by  the  range  for  each 
bandwidth  class  of  recorder  and  reproducer  system.  Additional  supplementary  procurement 
specifications  may  be  required  to  meet  a  particular  operational  requirement  of  the  ranges. 

16.1.  Tape  Width 

The  standard  nominal  tape  width  is  25.4  mm  (1  in.)  (see  Section  25  and  Table  A. 2-17). 

16.2.  Tape  Guiding 

The  tape  guidance  system  restricts  the  tape  angular  motion  to  ±0.15  mrad  (±30  seconds 
of  arc)  as  measured  by  the  interchannel  time  displacement  error  of  outer  tracks  on  the  same  head 
stack.  Make  sure  the  guidance  system  does  not  damage  the  tape. 

17.  Direct  Record  and  Reproduce  Systems 

Direct  recording  is  a  method  of  recording  information  signals  on  magnetic  tape  using 
high-frequency  ac  bias  recording  (see  definitions  at  Section  6.2  of  106-11  Chapter  6).  Two 
classes  of  systems,  wide  band  and  double  density,  are  included  in  these  standards  (see  Table 
A.2-4). 


17.1.  Direct  Record  Parameters 

The  following  items  describe  the  direct  record  parameters. 

a.  The  input  impedance  for  wide-band  and  double-density  recorders  shall  be  75  ohms 
nominal  across  the  specified  band. 

b.  Input  gain  adjustment  shall  be  provided  to  permit  sine-wave  signals  of  0.35  to  3.5  V  rms 
to  be  adjusted  to  produce  standard  record  level. 

c.  Ideally,  the  recorded  flux  level  on  tape  versus  frequency  should  be  constant.  To  approach 
this  ideal,  the  record  amplifier  transfer  characteristic  is  basically  a  constant  current  versus 
frequency  with  a  superimposed  compensation  characteristic  to  correct  only  for  loss  of 
recording  efficiency  with  frequency.  Results  of  the  test  described  in  Subparagraph  1.8 
Volume  III,  RCC  Document  118,  with  the  output  amplitude  at  the  2  percent  UBE 
frequency  used  as  the  0  dB  reference,  shall  be  no  greater  than  the  level  identified  in  Table 
A.2-8. 


Table  A.2-8.  Upper  Band  Edge  Maximum 

Level 

Percent  of  UBE  Frequency 

dB  Difference 

10 

0.5 

50 

1.0 

80 

1.6 

100 

2.0 
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d.  Record  bias  setting  information  is  contained  in  Table  A .2-4.  The  bias  frequency  shall  be 
greater  than  3.5  times  the  highest  direct  record  frequency  for  which  the  recorder  and 
reproducer  system  is  designed. 

17.2.  Standard  Record  Level 

The  standard  record  level  for  direct  record  systems  is  the  input  level  of  the  record  level 
set  frequency,  which  produces  an  output  signal  containing  one  percent  third  harmonic  distortion. 
The  conditions  necessary  to  establish  the  standard  record  level  include  appropriate  selection  of 
the  sinusoidal  reference  frequency  (record  level  set  frequency)  as  indicated  in  Table  A. 2-4  and 
proper  reproduce  amplifier  termination  as  defined  in  Figure  1-10  Volume  III,  RCC  Document 
118.  A  one  percent  third-harmonic  distortion  content  is  achieved  when  the  level  of  the  third 
harmonic  of  the  record  level  set  frequency  is  40  dB  +1  below  the  level  of  a  sinusoidal  signal  of 
30  percent  of  UBE  frequency  which  is  recorded  at  the  standard  record  level  (see  Section  5  for 
information  regarding  standard  test  and  operating  practices). 

17.3.  Reproduce  Parameters 

The  following  items  describe  the  reproduce  parameters. 

a.  For  wide-band  and  double-density  recorders,  the  output  impedance  shall  be  75  ohms 
nominal  across  the  specified  passband. 

b.  When  reproducing  a  signal  at  the  record  level  set  frequency  (recorded  at  the  standard 
record  level),  the  output  level  shall  be  a  minimum  of  1  V  rms  with  a  third  harmonic 
distortion  of  1  percent  and  a  maximum  second  harmonic  distortion  of  0.5  percent  when 
measured  across  a  resistive  load  of  75  ohms.  Lack  of  proper  output  termination  will  not 
cause  the  reproduce  amplifier  to  oscillate. 

17.4.  Tape  Speed  and  Flutter  Compensation 

The  average  or  long-term  tape  speed  must  be  the  same  during  record  and  reproduce  to 
avoid  frequency  offsets,  which  may  result  in  erroneous  data.  To  minimize  this  problem,  a 
reference  signal  may  be  applied  to  the  tape  during  record  and  the  signal  used  to  servo-control  the 
tape  speed  upon  reproduce;  however,  because  servo-control  systems  have  limited  correction 
capabilities  and  to  minimize  the  amount  of  equipment  required  at  the  ranges,  tape  speeds  and 
servo-control  signals  shall  conform  to  the  following  standards. 

a.  The  effective  tape  speed  throughout  the  reel  or  any  portion  of  the  reel  (in  absence  of  tape- 
derived  servo-speed  control)  shall  be  within  ±0.2  percent  of  the  standard  speed  as 
measured  by  the  procedures  described  in  Chapter  1,  Volume  III,  RCC  Document  118. 

b.  Sinusoidal  or  square  wave  speed  control  signals  are  recorded  on  the  tape  for  the  purpose 
of  servo-control  of  tape  speed  during  playback.  The  operating  level  for  speed-control 
signals  shall  be  10  dB  +5  below  standard  record  level  when  mixed  with  other  signals  or 
standard  record  level  when  recorded  on  a  separate  track. 

c.  The  constant- amplitude  speed-control  signal  shall  be  used  on  a  separate  track  for 
optimum  servo-speed  correction.  The  speed-control  signal  may  be  mixed  with  other 
signals  if  recording  requirements  so  demand  and  system  performance  permits.  Mixing  of 
the  speed-control  signal  with  certain  types  of  signals  may  degrade  system  performance 
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for  tapes  which  are  to  be  reproduced  on  tape  transports  with  low  time-base  error  capstan 
drive  systems  (refer  to  manufacturer).  Table  A.2-9  lists  speed-control  signal  frequencies. 
The  speed-control  signal  may  also  be  used  as  a  flutter  correction  signal. 


d.  Signals  to  be  used  for  discriminator  flutter  correction  systems  are  listed  in  Chapter  3, 
Table  3-5  and  Table  A.2-9.  See  the  previous  step  and  Chapter  3,  Table  3-5  for 
restrictions  on  use  of  flutter  correction  signals. 


Table  A.2-9. 

Constant  Amplitude  Speed  Control  Signals^^^ 

Tape  Speed 

Frequency*^^^  (kHz) 

(mm/s) 

(in/s) 

6096 

240 

400+0.01% 

800+0.01% 

3048 

120 

200+0.01% 

400+0.01% 

1524 

60 

100+0.01% 

200+0.01% 

762 

30 

50+0.01% 

100+0.01% 

381 

15 

25+0.01% 

50+0.01% 

190.5 

7-1/2 

12.5+0.01% 

25+0.01% 

95.5 

3-3/4 

6.5+0.01% 

12.5+0.01% 

47.6 

1-7/8 

3.125+0.01% 

6.25+0.01% 

Notes: 

1.  Mav  also  serve  as  discriminator  flutter-correction  reference  signal  (see  Chapter  3, 

Table  3-5). 

2.  Either  set  of  speed-control  signals  may  be  used  primarily  with  wideband  systems, 
but  only  the  higher  set  of  frequencies  is  recommended  for  double-density  systems. 

When  interchanging  tapes,  care  should  be  taken  to  ensure  that  the  recorded  speed- 
control  signal  is  compatible  with  the  reproduce  system’s  speed-control  electronics. 

18.  Timing,  Predetection,  and  Tape  Signature  Recording 

Described  in  the  following  subparagraphs  are  timing  signal,  predetection,  and  tape 
signature  recording. 

18.1.  Timing  Signal  Recording 

Modulated-carrier,  time-code  signals  (IRIG  A,  IRIG  B,  and  IRIG  G)  are  widely  used  and 
other  formats  are  available.  When  recording  IRIG  B  time-code  signals,  care  must  be  taken  to 
ensure  that  low-frequency  response  to  100  Hz  is  provided.  The  direct  record,  low  frequency 
cutoff  of  most  wide-band  recorders  is  400  to  800  Hz.  For  these  systems,  IRIG  B  time  code 
signals  should  be  recorded  on  an  FM  track  or  on  an  FM  subcarrier.  The  widest  bandwidth 
subcarrier  available  should  be  employed  to  minimize  time  delay.  ^  For  double-density  systems, 
all  time  code  signals  should  be  recorded  on  an  FM  track  or  an  FM  subcarrier. 


^  Timing  code  formats  are  found  in  IRIG  standard  200-04,  IRIG  Serial  Time  Formats  and  IRIG  standard  205-87, 
Parallel  Binary  and  Parallel  Binary  Coded  Decimal  Time  Code  Formats. 


A.2-31 


Telemetry  Standards,  IRIG  Standard  106-17  Annex  A. 2,  May  2017 


18.2.  Predetection  Recording 

Predetection  signals  have  been  translated  in  frequency  but  not  demodulated.  These 
signals  will  be  recorded  by  direct  (high  frequency  bias)  recording.  Parameters  for  these  signals 
are  in  Table  A.2-10. 


Table  A.2-10. 

Predetection  Carrier  Parameters 

Tape  Speed 

Predetection  Carrier  Center  Frequency 

Wide  Band 

Double  Density 

A  (kHz) 

B  (kHz) 

mm/s 

in/s 

mm/s 

in/s 

6096 

(240) 

3048.0 

(120) 

1800 

2400 

3048 

(120) 

1524.0 

(60) 

900 

1200 

1524 

(60) 

762.0 

(30) 

450.0 

600 

762 

(30) 

381.0 

(15) 

225.0 

300 

381 

(15) 

109.5 

(7.5) 

112.5 

150 

Notes: 

1 .  The  predetection  record/playback  passband  is  the  carrier  center  frequency  ±66.7  percent. 

2.  Use  center  frequencies  in  column  B  when  data  bandwidth  exceeds  the  capabilities  of  those 
in  column  A. 

18.3.  Tape  Signature  Recording 

For  data  processing  using  wide -band  and  double-density  recorders  and  reproducers,  a 
tape  signature  recorded  before  or  after  the  data,  or  both  before  and  after  the  data,  provides  a 
method  of  adjusting  the  reproducer  head  azimuth  and  reproduce  equalization.  A  means  is  also 
provided  for  verifying  the  proper  operation  of  equipment  such  as  playback  receivers  and  bit 
synchronizers  used  to  retrieve  the  recorded  data. 


A  PCM  signature  is  recommended  where  primarily  PCM  data  is  recorded.  A  swept- 
frequency  or  white-noise  signature  may  be  used  for  other  data  such  as  frequency  division 
multiplexing  or  wide  band  FM.  The  procedures  for  recording  and  using  these  signatures  are 
given  in  Section  A  recommended  preamble/postamble  signal  for  recorder/reproducer 
alignment  is  included  in  Paragraph  2J_. 


Caution  should  be  used  when  multiplexing  other  signals  with  the  speed- 
control  signal.  In  the  vicinity  of  the  frequency  of  the  speed-control  signal  (fsc 
±10  percent),  the  level  of  individual  extraneous  signals  including  spurious, 
harmonics,  and  noise  must  be  40  dB  or  more  below  the  level  of  the  speed- 
control  signal.  A  better  procedure  is  to  leave  one  octave  on  either  side  of  the 
speed-control  signal  free  of  other  signals. 


19.  FM  Record  Systems 

For  these  FM  record  systems,  the  input  signal  modulates  a  voltage-controlled  oscillator, 
and  the  output  is  delivered  to  the  recording  head.  High  frequency  bias  may  be  used  but  is  not 
required.  These  standards  shall  apply. 

a.  Tape  and  Reel  Characteristics.  Section  22  and  all  related  subparagraphs  shall  apply. 
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b.  Tape  Speeds  and  Corresponding  FM  Carrier  Frequencies.  See  Table  A.2-11. 

c.  FM  Record/Reproduce  Parameters.  See  Table  A.2-11. 


Table  A.2-11.  Wide-band  and  Double-Density  FM  Record  Parameters 


Tape  Speed 

Carrier 

Center 

Frequency 

Carrier  Deviation 
Limits^^^ 

Modulation 

Frequency 

Response 

Band 

Limits 

Plus 

Deviation 

Minus 

Deviation 

Wide  Band  FM 

mm/s 

in/s 

kHz 

kHz 

kHz 

kHz 

dB^2) 

Group  I 

47.6 

1-7/8 

6.750 

9.450 

4.050 

dc  to  1.250 

+1 

95.2 

3-3/4 

13.500 

18.900 

8.100 

dc  to  2.500 

+1 

190.5 

7-1/2 

27.000 

37.800 

16.200 

dc  to  5.000 

+1 

381.0 

15 

54.000 

75.600 

32.400 

dc  to  10.000 

+1 

762.0 

30 

108.000 

151.200 

64.800 

dc  to  20.000 

+1 

1524.0 

60 

216.000 

302.400 

129.600 

dc  to  40.000 

+1 

3048.0 

120 

432.000 

604.800 

259.200 

dc  to  80.000 

+1 

Double 

Density 

Group  II 

mm/s 

in/s 

47.6 

1-7/8 

14.062 

18.281 

9.844 

dc  to  7.810 

±1,-3 

95.2 

3-3/4 

28.125 

36.562 

19.688 

dc  to  15.620 

±1,-3 

95.2 

3-3/4 

190.5 

7-1/2 

56.250 

73.125 

39.375 

dc  to  31.250 

±1,-3 

190.5 

7-1/2 

381.0 

15 

112.500 

146.250 

78.750 

dc  to  62.50 

±1,-3 

381.0 

15 

62.0 

30 

225.000 

292.50 

157.50 

dc  to  125.0 

±1,-3 

762.0 

30 

1524.0 

60 

450.000 

585.0 

315.0 

dc  to  250.0 

±1,-3 

1524.0 

60 

3048.0 

120 

900.000 

1170.0 

630.0 

dc  to  500.0 

±1,-3 

3048.0 

120 

6096.0 

240 

1800.000 

2340.0 

1260.0 

dc  to  1000.0 

±1,-3 

Notes: 

1 .  Input  voltage  levels  per  step  e  below. 

2.  Frequency  response  referred  to  1-kHz  output  for  FM  channels  13.5  kHz  and  above,  and  100 
Hz  for  channels  below  13.5  kHz. 


d.  Speed  Control  and  Compensation.  Subsection  17.4  shall  apply.  Note  that  a  separate 
track  is  always  required  for  speed  control  and  flutter  compensation  signals  with  a  single¬ 
carrier  FM  system. 

e.  FM  Record  Parameters.  For  FM  record  systems,  an  input  voltage  of  1  to  lOV  peak-to- 
peak  shall  be  adjustable  to  produce  full  frequency  deviation. 

f.  Deviation  Direction.  Increasing  positive  voltage  gives  increasing  frequency. 
Predetection  recorded  tapes  may  be  recorded  with  reverse  deviation  direction  because  of 
the  frequency  translation  techniques  employed. 

g.  FM  Reproduce  Systems.  Output  levels  are  for  signals  recorded  at  full  deviation.  In 
wide-band  and  double-density  FM  systems,  the  output  is  2  V  peak-to-peak  minimum 
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across  a  load  impedance  of  75  ohms  +10  percent.  Increasing  input  frequency  gives  a 
positive  going  output  voltage. 


20.  PCM  Recording 

The  PCM  signals  may  be  successfully  recorded  using  several  different  methods. 

Methods  included  in  these  standards  are  predetection  recording,  post-detection  recording,  and 
serial  HDDR.  Parallel  HDDR  methods  are  not  included. 

20.1.  Predetection  PCM  Recording 

This  method  employs  direct  recording  of  the  signal  obtained  by  heterodyning  the  receiver 
IF  signal  to  one  of  the  center  frequencies  listed  in  Table  A. 2-10  without  demodulating  the  serial 
PCM  signal  (see  Figure  A.2-12).  The  maximum  recommended  bit  rate  for  predetection 
recording  of  NRZ  data  is  equal  to  the  predetection  carrier  frequency,  for  example,  900  kb/s  for  a 
900  kHz  predetection  carrier.  The  maximum  recommended  bit  rate  for  predetection  recording  of 
Bi(j)  data  is  equal  to  one-half  the  predetection  carrier  frequency.  For  bit  rates  greater  than  one- 
half  the  maximum  recommended  rates,  the  preferred  method  of  detection  is  to  convert  the  signal 
to  a  higher  frequency  before  demodulation. 

20.2.  Post-Detection  PCM  Recording 

The  serial  PCM  signal  (plus  noise)  at  the  video  output  of  the  receiver  demodulator  is 
recorded  by  direct  or  wide  band  FM  recording  methods  without  first  converting  the  PCM  signal 
to  bi-level  form  (see  Figure  A.2-12).  Table  A.2-12  lists  maximum  bit  rates  versus  tape  speed  for 
these  recording  methods.  The  minimum  recommended  reproduce  bit  rates  are  10  kb/s  for  post¬ 
detection  direct  Bicj)  and  10  bits  per  second  for  post-detection  FM  (see  Chapter  4,  Subparagraph 

4.2.2. C). 


Table  A.2-12.  Maximum  Recommended  Bit  Rates,  Post-Detection 

Recording^^^ 


Tape  Speed 

Post-D 

Post 

t-FM 

Wide  Band 

Double  Density 

Direct 

Bid)  (kb/s) 

(mm/s) 

(in/s) 

(mm/s) 

(in/s) 

Bid)  (kb/s) 

IMJvZi  l^KD/SJ 

6096.0 

(240) 

3048.0 

(120) 

1800 

900 

1800 

3048.0 

(120) 

1524.0 

(60) 

900 

450 

900 

1524.0 

(60) 

762.0 

(30) 

450.0 

225 

450 

762.0 

(30) 

381.0 

(15) 

225.0 

112 

225 

381.0 

(15) 

109.5 

(7-1/2) 

112.5 

56 

112 

190.5 

(7-1/2) 

95.2 

(3-3/4) 

56 

28 

56 

95.2 

(3-3/4) 

- 

- 

28 

14 

28 

47.6 

(1-7/8) 

- 

- 

14 

7 

14 

Note: 

1 .  Direct  recording  of  NRZ  signals  is  NOT  recommended  unless  the  signal  format  is  carefully 
designed  to  eliminate  low-frequency  components  for  any  data  expected. 
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20.3.  Serial  High-Density  Digital  Recording 

Serial  HDDR  is  a  method  of  recording  PCM  data  on  a  magnetic  tape  that  involves 
applying  the  data  to  one  track  of  the  recorder  as  a  bi-level  signal. 

20.4.  Direct  Recording  of  PCM  Telemetry  Data 

The  following  subparagraphs  deal  with  standards  for  direct  recording  of  PCM  telemetry 
data  using  a  wide  band  analog  instrumentation  recorder  or  reproducer  system.  Direct  recording 
is  described  in  Section  17.  The  recommended  PCM  codes,  maximum  bit  rates,  record  and 
reproduce  parameters,  and  the  magnetic  tape  requirements  are  also  described. 

20.4.1.  PCM  Codes 

The  recommended  codes  for  serial  high-density  PCM  recording  are  Bi(j)-L  and  RNRZ-L. 
The  maximum  recommended  bit  packing  densities  (for  wide  band  recording)  are  590  bits  per 
millimeter  (b/mm)  (15  kb/inch)  for  Bi(j)-L  and  980  b/mm  (25  kb/inch)  for  RNRZ-L.  Refer  to 
Table  A. 2- 13  for  maximum  recommended  bit  rates  versus  standard  tape  speeds.  The  minimum 
recommended  reproduce  bit  rates  are  5  kb/s  for  Bi(()-L  and  200  kb/s  for  RNRZ-L.  Details  of  the 
implementation  are  discussed  in  Section  3. 


Table  A.2-13.  Maximum  Recommended  Bit  Rates 


Tape  Speed 

Bif  L  (kb/s) 

RNRZ-L  (kb/s) 

Wide  Band 

Double  Density 

(mm/s) 

(in/s) 

(mm/s) 

(in/s) 

6096.0 

(240) 

3048.0 

(120) 

3600 

6000 

3048.0 

(120) 

1524.0 

(60) 

1800 

3000 

1524.0 

(60) 

762.0 

(30) 

900 

1500 

762.0 

(30) 

381.0 

(15) 

450 

750 

381.0 

(15) 

109.5 

(7-1/2) 

225 

375 

190.5 

(7-1/2) 

95.2 

(3-3/4) 

112 

187^^) 

95.2 

(3-3/4) 

— 

56 

93(1) 

47.6 

(1-7/8) 

— 

28 

46^1^ 

Note: 

1 .  Reproducing  data  at  bit  rates  less  than  200  kb/s  is  not  recommended  when  using  RNRZ-L. 


20.4.2.  BifLCode. 

The  Bi(j)-L  code  is  recommended  for  direct  recording  under  the  following  conditions: 
The  bit  rate  of  the  data  to  be  recorded  does  not  exceed  the  maximum  bit  rates  for  Bi(j)-L  (see 
Table  A.2-13),  and  the  amount  of  tape  required  for  mission  recording  by  this  method  is  not  a 
severe  operational  constraint. 

20.4.3.  RNRZ-L  Code. 

The  RNRZ-L  code  is  recommended  for  direct  recording  under  any  of  the  following 
conditions:  the  bit  rate  of  the  data  to  be  recorded  exceeds  the  maximum  recommended  bit  rates 
for  Bi(j)-L  (see  Table  A.2-13)  or  maximum  tape  recording  time  is  needed. 

a.  To  minimize  baseline  wander  anomalies,  RNRZ-L  is  NOT  recommended  if  the 
reproduced  bit  rate  is  less  than  200  kb/s. 
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b.  The  RNRZ-L  shall  be  implemented  using  a  15-stage  shift  register  and  modulo-2  adders 
(see  Figure  A.2-13).  The  randomized  bit  stream  to  be  recorded  is  generated  by  adding 
(modulo-2)  the  input  bit  stream  to  the  modulo-2  sum  of  the  outputs  of  the  14th  and  15th 
stages  of  the  shift  register.  In  the  decoder,  the  randomized  bit  stream  is  the  input  to  the 
shift  register. 


To 

Recorder 

Input* 


To 

Recorder 

Input^ 


( See  figure  D  -  2,  appendix  D. ) 


( See  figure  D  -  3,  appendix  D. ) 


'  When  Biiji-  L  is  recorded. 

2  When  RNRZ-L  is  recorded. 

^  The  Bi(t)-L  converter  may  be  an  integral  part  of  the  Bit  Sync. 

''  Bit  Sync  input  code  selector  set  to  NRZ-L  if  RNRZ-L  is 
recorded  or  to  Bi(|i-L  if  Bi(|>-L  is  recorded. 


Figure  A.2-13.  Serial  high-density  digital  record  and  reproduce 


20.4.4.  Record  Parameters 

The  record  parameters  are  explained  in  the  following  items. 


a.  High-density  PCM  data  shall  be  recorded  in  compliance  with  the  direct  record  parameters 
detailed  in  Subsection  17.1  including  the  use  of  an  ac  bias  signal  level  that  produces  the 
required  2  dB  over-bias  condition. 
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b.  The  peak- to- peak  level  of  the  PCM  input  signal  shall  be  equal  to  twice  the  rms  value  of 
the  signal  amplitude  used  to  establish  the  standard  record  level  with  a  tolerance  of  +25 
percent  (see  Subparagraph  17.2). 

c.  The  signal  to  be  recorded  must  be  bi-level.  Bi-level  signals  are  signals  where  only  two 
levels  are  present.  Therefore,  signals  containing  noise  must  be  converted  to  bi-level 
signals  before  they  are  recorded. 

d.  To  minimize  the  effects  of  tape  dropouts,  serial  high-density  digital  data  should  not  be 
recorded  on  the  edge  tracks  of  the  tape. 

20.4.5.  Reproduce  Parameters 

All  reproduce  parameters  in  Subsection  17.3  shall  apply. 

20.4.5.1.  PCM  Signature 

A  PCM  signature  should  be  recorded  before  or  after  or  both  before  and  after  the  data  to 
provide  a  method  for  adjusting  the  reproduce  head  azimuth  and  the  reproducer  equalizers.  The 
data  rate  of  the  PCM  signature  should  be  the  same  as  the  rate  of  the  data  to  be  recorded  (see 
Section  7  for  tape  signature  recording). 

20.4.5.2.  Phase  Equalizer 

Correct  phase  equalization  is  very  important  to  the  reconstruction  of  the  serial  high- 
density  digital  data.  Adjustable  phase  equalizers  are  desirable  but  not  mandatory. 

20.4.6.  Magnetic  Tape 

High-density  digital  (HDD)  magnetic  tapes  are  recommended;  however,  wide  band 
instrumentation  tapes  can  be  used  on  recorder  and  reproducer  systems  with  1.27  mm  (0.050  inch) 
track  widths  (see  Sections  22  through  27  below). 

20.4.7.  Tape  Copying 

The  following  practices  are  recommended  when  making  copies  of  original  data  tapes. 

a.  Convert  data  reproduced  from  the  original  tape  to  a  bi-level  signal  prior  to  recording  a 
copy. 

b.  Align  reproduce  head  azimuth  to  original  tape. 

c.  Adjust  reproducer  equalizers  correctly. 

d.  Prior  to  recording  the  copy,  use  the  recorded  PCM  signature  to  optimize  the  quality  of  the 
reproduced  data. 

20.4.8.  PCM  Bit  Synchronizer 

The  PCM  bit  synchronizer  should  contain  circuitry  to  reestablish  the  baseline  reference 
PCM  signal  (a  dc  restorer  circuit).  This  circuit  is  essential  when  reproducing  RNRZ-L  at 
reproduced  bit  rates  less  than  1  Mb/s.  The  PCM  bit  synchronizer  loop  bandwidth  should  be 
selected  for  optimum  performance  between  0. 1  and  3  percent  of  the  bit  rate. 


NOTE^ 

If  an  appropriate  PCM  bit  synchronizer  is  not  available,  the 

tape  can  be  copied  directly;  however,  the  SNR  will  be 

decreased. 
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21.  Preamble  Recording  for  Automatic  or  Manual  Recorder  Alignment 

A  preamble  (or  postamble)  may  be  recorded  on  the  same  tape  as  the  data  signal  with 
known  frequency  and  amplitude  elements  which  will  allow  automatic  or  manual  alignment  of  the 
signal  electronics  to  optimize  the  performance  of  the  playback  system.  Reproduce  azimuth, 
equalization,  and  FM  demodulator  sensitivity  may  be  adjusted  at  all  available  tape  speeds.  The 
preamble  may  be  used  for  manual  adjustment  of  any  instrumentation  magnetic  tape  recorder/ 
reproducer  (wide  band  and  double  density).  Automatic  adjustment  requires  a  recorder/ 
reproducer  specifically  designed  with  the  capability  to  automatically  adjust  one  or  more  of  the 
following:  reproduce-head  azimuth,  amplitude  equalization,  phase  equalization,  and  FM 
demodulator  sensitivity.  The  signal  source  may  be  internal  to  the  recorder  or  may  be  externally 
generated. 

21.1.  Alignment,  Direct  Electronics 

Direct  electronics  shall  use  a  1/1 1  band  edge  square  wave  for  both  manual  and  automatic 
alignment  as  given  in  this  annex. 

21.2.  Alignment,  FM  Electronics 

The  FM  electronics  shall  use  a  1/1 1  band  edge  square  wave  and  +1.414  Vdc  or  0.05  Hz 
square  wave  for  both  manual  and  automatic  alignment  as  given  in  this  annex. 

22.  Magnetic  Tape  Standards:  General 

The  following  standards  define  terminology,  establish  key  performance  criteria,  and 
reference  test  procedures  for  longitudinally-oriented  oxide,  unrecorded  magnetic  tape  designed 
for  instrumentation  recording,'*  and  reference  specifications  for  19  mm  (0.75  in)  cassettes 
designed  for  digital  helical  scan  recording  and  S-VHS  cassettes  designed  for  12.65  mm  (1/2  in) 
digital  helical  scan  recording.  Classes  of  instrumentation  recording  tapes  include  high-resolution 
(HR)  tapes  used  for  wide  band  recording,  HDD  tapes  used  for  high-density  digital  PCM 
recording,  and  high  energy  (HE)  tapes  used  for  double-density  recording. 

Coercivities  of  HR  and  HDD  tapes  are  in  the  range  of  275  to  350  oersteds.  High-energy 
tapes  have  coercivities  of  600  to  800  oersteds.  Nominal  base  thickness  is  25.4  pm  (1.0  mil)  and 
nominal  coating  thickness  is  5  pm  (200  microinches)  for  all  tapes.  Where  required,  limits  are 
specified  to  standardize  configurations  and  to  establish  the  basic  handling  characteristics  of  the 
tape.  Limits  placed  on  the  remaining  requirements  must  be  determined  by  the  tape  user  in  light 
of  the  intended  application  and  interchangeability  requirements  imposed  on  the  tape  (see  Table 
A. 2-14  for  examples  of  suggested  requirement  limits). 


Table  A.2-14.  Suggested  Tape  Requirement  Limits 

Paragraph  No. 

Tape  Requirement 

Suggested  Limits 

27.1 

Bias  Level 

+2.0  dB  from  MCT 

27.2 

Record  Level 

+2.0  dB  from  MCT 

27.3 

Wavelength  Response  (Table  A. 2-15) 

Federal  Specifications  may  be  used  to  replace  paragraphs  contained  in  this  chapter  where  applicable.  High  output 
and  HDD  tapes  are  not  included  in  the  Federal  Specifications.  Other  standards  are  listed  in  Paragraph  ANNEX 


A.21. 
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27.4 

Output  at  0.1  UBE  Wavelength 

1.5  dB  from  MCT 

27.5 

Short  Wavelength  Output  Uniformity 

2.5  dB  (HR  tape);  2.5  dB  (HE 
tape) 

Center  Tracks  Edge  Tracks 

27.6 

Dropouts  per  30  m  (100  ft)  (average) 

5 

1 

HR  Tape 

HDD  Tape 

10 

1 

20 

HE  Tape 

30 

27.7 

Durabilitv  (See  Table  A. 2-16) 

27.8 

Modulation  Noise 

1  dB  maximum 

Table  A.2-15. 

Suggested  Wavelength  Response  Requirements 

HR  and  HDD  Tape 

Measurement  Wavelength 

HR  Response 

HDD  Response 

(pm) 

(mils) 

(dB) 

(dB) 

3810.00 

(150.000) 

1.00 

2.00 

254.00 

(10.000) 

1.00 

1.00 

15.14 

(0.600) 

0.00 

0.00 

6.35 

(0.250) 

1.50 

1.50 

3.18 

(0.125) 

2.00 

2.00 

2.54 

(0.100) 

2.50 

2.50 

2.03 

(0.080) 

2.50 

2.50 

1.52 

(0.060) 

3.00 

3.00 

High-Energy  Tape 

Measurement  Wavelength 

HE  Wavelength  Response  (dB) 

(pm) 

(mils) 

25.40 

(1.000) 

2.00 

12.70 

(0.500) 

2.00 

7.62 

(0.300) 

0.00 

3.18 

(0.125) 

2.50 

1.52 

(0.060) 

2.50 

1.02 

(0.040) 

3.00 

0.76 

(0.030) 

3.50 

Table  A.2-16.  Durability  Signal  Losses 

Designated  1 

rape  Length 

Number  of  Allowable  Signal  Losses 
(per  pass) 

Meters 

Feet 

762 

(2500) 

2 

1097 

(3600) 

2 

1402 

(4600) 

2 

1524 

(5000) 

2 

2195 

(7200) 

3 

2804 

(9200) 

3 

3292 

(10,800) 

4 
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23.  Definitions 

Underlined  terms  appearing  within  definitions  indicate  that  these  terms  are  defined 

elsewhere  in  Section  23.0.  For  the  purpose  of  this  standard,  the  following  definitions  apply. 

Back  Coating.  A  thin  coating  of  conductive  material  (for  example,  carbon)  bonded  to  the  surface 
of  a  magnetic  tape  opposite  the  magnetic-coated  surface  for  reducing  electrostatic  charge 
accumulation  and  for  enhancing  high-speed  winding  uniformity.  Resistivity  of  the  back 
coating  should  be  1  megohm  per  square  or  less,  whereas  the  oxide-coated  magnetic 
surface  resistivity  is  much  higher  (also  see  magnetic  oxide  coating). 

Base.  The  material  on  which  the  magnetic  oxide  coating  (and  back  coating,  if  employed)  is 
applied  in  the  manufacture  of  magnetic  tapes.  For  most  applications,  polyester-base 
materials  are  currently  employed. 

Bias  Level.  The  level  of  high  frequency  ac  bias  current  or  voltage  in  a  direct  record  system 

needed  to  produce  a  specified  level  of  a  UBE  frequency  sine-wave  signal  at  a  particular 
tape  speed.  Bias  level  is  usually  adjusted  to  produce  maximum  output  or  increased 
beyond  maximum  to  depress  the  output  2  dB. 

Bi-Directional.  Ability  of  a  magnetic  tape  to  record  and  to  reproduce  a  specified  range  of  signals 
within  specified  tolerances  of  various  characteristics  when  either  end  of  the  tape  on  the 
reel  is  used  as  the  leading  end. 

Binder.  Material  in  which  the  magnetic  oxide  particles  or  back-coating  particles  are  mixed  to 
bond  them  to  the  base  material. 

Blocking.  Failure  of  the  magnetic  coating  to  adhere  to  the  base  material  because  of  layer-to- 
layer  adhesion  in  a  wound  tape  pack. 

Center  Tracks.  On  a  recorded  tape,  center  tracks  are  those  that  are  more  than  one-track  distance 
from  either  edge  of  the  tape,  for  example,  tracks  2  through  13  of  a  14-track  tape  or  tracks 
2  through  27  of  a  28-track  tape. 

Dropout.  A  reproduced  signal  of  abnormally  low  amplitude  caused  by  tape  imperfections  severe 
enough  to  produce  a  data  error.  In  digital  systems,  dropouts  produce  bit  errors. 

Edge  Tracks.  The  data  tracks  nearest  the  two  edges  of  a  recorded  magnetic  tape,  for  example, 
tracks  1  and  14  of  a  14-track  tape. 

Erasure.  Removal  of  signals  recorded  on  a  magnetic  tape  to  allow  reuse  of  the  tape  or  to  prevent 
access  to  sensitive  or  classified  data.  Instrumentation  recorders  and  reproducers  do  not 
usually  have  erase  heads,  so  bulk  erasers  or  degaussers  must  be  employed. 

E- Value.  The  radial  distance  by  which  the  reel  flanges  extend  beyond  the  outermost  layer  of 
tape  wound  on  a  reel  under  a  tape  tension  of  3.33  to  5.56  newtons  (12  to  20  ounces  of 
force)  per  inch  of  tape  width.  Inadequate  E-value  may  prohibit  the  use  of  protective  reel 
bands. 

High-Density  Digital  Magnetic  Tape.  Instrumentation  magnetic  tape  with  nominal  base 

thickness  of  25.40  pm  (1  mil)  and  coercivity  of  275  to  350  oersteds  used  to  record  and 
reproduce  high-density  digital  (PCM)  signals  with  per-track  bit  densities  of  590  b/mm 
(15  kb/inch)  or  greater. 

High-Energy  Magnetic  Tape.  Magnetic  tapes  having  coercivity  of  600  to  800  oersteds  and 

nominal  base  thickness  of  25.4  pm  (1  mil)  used  for  double-density  analog  recording  and 
high-density  digital  recording  above  980  b/mm  (25  kb/inch). 
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High-Resolution  Magnetic  Tape.  Instrumentation  magnetic  tape  used  for  recording  on  wide 
band  recorder  and  reproducer  systems.  The  HR  and  HDD  tapes  may  have  identical 
coatings  and  coercivities  (275  to  350  oersteds)  but  differ  in  the  extent  and  type  of  testing 
conducted  by  the  manufacturer. 

Layer-to-Layer  Signal  Transfer  (Print  Through).  Transfer  of  a  signal  to  a  layer  of  a  wound 

magnetic  tape  originating  from  a  signal  recorded  on  an  adjacent  layer  of  tape  on  the  same 
reel.  Saturation-level  recorded  signals  and  tape  storage  at  elevated  temperatures  are 
likely  contributors  to  this  effect. 

Magnetic  Oxide  Coating.  Material  applied  to  a  base  material  to  form  a  magnetic  tape.  The 

magnetic  oxide  coating  contains  the  oxide  particles,  the  binder,  and  other  plasticizing  and 
lubricating  materials  necessary  for  satisfactory  operation  of  the  magnetic  tape  system 
(also  see  back  coating). 

Manufacturer's  Centerline  Tape  (MCT).  A  tape  selected  by  the  manufacturer  from  his 

production,  where  the  electrical  and  physical  characteristics  are  employed  as  reference 
standards  for  all  production  tapes  to  be  delivered  during  a  particular  contractual  period. 
Electrical  characteristics  include,  but  are  not  limited  to,  bias  level,  record  level,  output  at 
0.1  UBE,  and  wavelength  response.  The  MCTs  are  not  usually  available  for  procuring 
agency  use. 

Manufacturer’s  Secondary  Centerline  Tape  (MSCT).  A  tape  selected  by  a  manufacturer  from  his 
production  and  provided  in  lieu  of  an  MCT.  On  the  MSCT,  the  electrical  characteristics 
may  depart  from  the  MCT  characteristics,  but  calibration  data  referenced  in  the  MCT  are 
provided.  All  other  characteristics  of  the  MSCT  are  representative  of  the  manufacturer's 
product. 

Modulation  Noise.  Noise  riding  on  a  reproduced  signal  that  is  proportional  to  the  amplitude  of 
the  recorded  signal  (below  saturation)  and  results  from  tape-coating  irregularities  in 
particle  size,  orientation,  coercivity,  and  dispersion. 

Record  Eevel.  The  level  of  record  current  or  voltage  required  to  achieve  a  specified  reproduce 
output  level  with  bias  level  previously  set  to  the  correct  value.  In  direct  record  systems, 
standard  record  level  is  the  level  of  a  0.1  UBE  frequency  signal  required  to  produce  1 
percent  third  harmonic  distortion  in  the  reproduced  output  signal  because  of  tape 
saturation. 

Scatterwind.  Eateral  displacements  of  tape  wound  on  a  reel  which  gives  an  irregular  appearance 
to  the  side  surfaces  of  a  tape  pack.  Scatterwind  can  result  from  such  things  as  poorly 
controlled  tape  tension,  guiding,  static  electrical  charge,  and  poor  tape  slitting. 

Shedding.  Eoss  of  magnetic  coating  from  tape  during  operation  on  a  tape  transport.  Excessive 
shedding  causes  excessive  dropout. 

Short  Wavelength  Output  Uniformity.  A  measure  of  high-frequency  reproduce  signal  amplitude 
uniformity  caused  by  oxide  coating  variations. 

Upper  Band  Edge.  The  highest  frequency  that  can  be  recorded  and  reproduced  at  a  particular 
tape  speed  in  the  direct  record  mode.  The  UBE  signals  are  used  in  setting  bias  level;  0. 1 
UBE  signals  are  used  to  set  record  level. 

Wavelength  Response.  The  record  and  reproduce  characteristic  of  a  magnetic  tape  which 

depends  on  tape  formulation,  coating  thickness,  and  other  tape  physical  parameters  and  is 
a  function  of  the  wavelength  recorded  on  the  tape  (tape  speed  divided  by  signal 
frequency)  rather  than  the  actual  frequency  recorded. 
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Working  Length.  Length  of  tape  usable  for  reliable  recording  and  reproduction  of  data.  Actual 
tape  length  on  a  reel  exceeds  the  working  length  to  provide  for  tape  start  and  stop  at  each 
end  of  the  reel  without  loss  of  data. 

Working  Reference  Tape  (WRT).  A  tape  or  tapes  of  the  same  type  as  an  MCT  or  MSCT 

selected  by  the  user  and  calibrated  to  the  MCT  or  MSCT.  The  WRTs  are  employed  in 
conducting  tests  on  tape  types  during  a  procurement  activity  and  for  aligning  and  testing 
recorder  and  reproducer  systems  to  minimize  running  the  MCT  or  MSCT. 

24.  General  Requirements  for  Standard  Instrumentation  Tapes  and  Reels 

The  following  subparagraphs  describe  the  requirements  for  tapes  and  reels. 


24.1.  Reference  Tape  System 

To  establish  a  set  of  test  procedures  that  can  be  performed  independently  and  repeatedly 
on  different  manufacturers'  tape  transports,  a  centerline  reference  tape  system  employing  MCT, 
MSCT,  or  WRTs  as  required,  should  be  used.  The  reference  tape  system  provides  a  centerline 
tape  against  which  tape  or  tape  recorder  specifications  may  be  tested  or  standard  tapes  for 
aligning  operational  recorders. 

24. 1 . 1 .  Manufacturer's  Centerline  Tape 

The  electrical  characteristics  provided  for  a  manufacturer's  centerline  tape  include,  but 
are  not  limited  to,  bias  level,  record  level,  wavelength  response,  and  output  at  0. 1  UBE 
wavelength.  The  physical  characteristics  of  the  MCT  shall  also  represent  the  manufacturer's 
production  and  shall  be  representative  of  all  production  tape  delivered  during  any  resultant 
contractual  period  (see  MCT  definition  in  Section  23) 

24.1.2.  Manufacturer's  Secondary  Centerline  Tape 

On  the  MSCT,  the  electrical  characteristics  are  calibrated  to  the  manufacturer's  reference 
tape,  and  calibration  data  are  supplied  with  the  MSCT.  The  physical  characteristics  of  the 
MSCT  shall  represent  the  manufacturer's  production  (see  secondary  MSCT  definition  in  Section 


24.1.3.  W orking  Reference  Tape 

Working  reference  tapes  shall  be  of  the  same  type  as  those  under  procurement  or  test  and 
shall  be  used  in  place  of  a  MCT  or  MSCT  for  all  applicable  test  procedures  (see  WRT  definition 
in  Section  23). 


The  MCT  or  MSCT  shall  be  a  full-length  tape  of  25.4  mm  (1  in.)  width, 
wound  on  a  266.7  mm  (10  1/2  in.)  or  355.6  mm  (14  in.)  reel  or  as  designated 
by  the  tape  user.  The  center  one-third  of  the  working  tape  length  shall  be  used 
as  the  calibrated  working  area. 


24. 1 .4.  Test  Recorder  and  Reproducer 

A  laboratory  quality  test  recorder  shall  be  designated  for  use  with  the  reference  tape 
system  during  any  magnetic  tape  procurement  and  test  program.  The  recorder  selected  shall 
meet  the  requirements  specified  in  this  annex. 

24.1.5.  MCT/MSCT/WRT  Use 

Using  MCT  or  MSCT  as  a  reference,  the  tape  user  performs  all  tests  necessary  to 
determine  if  the  manufacturer's  centerline  performance  values  meet  operational  and  recorder 
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requirements.  All  acceptable  centerline  tapes  are  retained  by  the  tape  user  as  references  in 
subsequent  acceptance  test  procedures  performed  in  support  of  resultant  contracts  or  contractual 
periods.  A  working  reference  tape,  which  has  been  calibrated  to  an  MCT  or  MSCT,  is  used  as 
the  actual  working  reference  in  the  applicable  testing  procedures  outlined  in  Volume  III,  RCC 
Document  118.  Dropout  tests  should  use  a  tape  other  than  the  MSCT  or  WRT. 

24.2.  Marking  and  Identifying 

See  Federal  Specification  W-T-1553B.^ 

24.3.  Packaging 
Specified  by  user. 

24.4.  Winding 

The  tape  shall  be  wound  on  the  reel  or  hub  with  the  oxide  surface  facing  toward  the  hub 
(“A”  wind).  The  front  of  the  wound  reel  is  defined  as  that  flange  visible  when  viewing  the  tape 
reel  with  the  loose  end  of  the  tape  hanging  from  the  viewer's  right. 

24.5.  Reels  and  Hubs 

Reels  and  hubs  shall  conform  to  the  tape  user  specified  requirements  of  Federal 
Specification  W-R-175.^ 

24.6.  Radial  Clearance  (E- Value) 

For  all  tape  lengths,  use  3.175  mm  (0.125  inch),  (See  E-Value  definition  in  Section  23). 

24.7.  Flammable  Materials 

Flammable  materials  shall  not  be  a  part  of  the  magnetic  tape.  Flammable  materials  will 
ignite  from  a  match  flame  and  will  continue  to  bum  in  a  still  carbon  dioxide  atmosphere. 

24.8.  Toxic  Compounds 

Compounds  that  produce  toxic  effects  in  the  environmental  conditions  normally 
encountered  under  operating  and  storing  conditions  as  defined  in  Subsection  25.2  shall  not  be 
part  of  the  magnetic  tape.  Toxicity  is  defined  as  the  property  of  the  material  that  has  the  ability 
to  do  chemical  damage  to  the  human  body.  Highly  toxic  or  corrosive  compounds  produced 
under  conditions  of  extreme  heat  shall  be  identified  and  described  by  the  manufacturer. 

25.  General  Characteristics  of  Instrumentation  Tapes  and  Reels 

The  following  subparagraphs  describe  the  general  characteristics  for  tapes  and  reels. 


^  General  Services  Administration.  “General  Specification  for  Tape,  Instrumentation,  Recording,  Magnetic  Oxide- 
Coated.”  Federal  Specification  W-T-1553B.  12  August  1996.  Canceled  with  no  replacement.  Retrieved  3  June 
2015.  Available  at  http://quicksearch.dla.mil/qsDocDetails. ast)x?ident  number=49387. 

®  General  Services  Administration.  “General  Specification  for  Reels  and  Hubs  for  Magnetic  Recording  Tape.”  W- 
R-175D.  22  December  1986.  Canceled  with  no  replacement.  Retrieved  3  June  2015.  Available  at 
http://quicksearch.dla.mil/qsDocDetails.aspx7ident  number=49028. 
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25.1.  Dimensional  Specifications 

Magnetic  tape  shall  be  supplied  on  flanged  reels  in  the  standard  lengths,  widths,  and  base 
thicknesses  outlined  in  Table  A. 2- 17.  Reel  and  hub  diameters  are  taken  from  Federal 
Specification  W-R-175. 


Table  A.2-17.  Tape  Dimensions 

Dimension 

Millimeters 

Inches 

Tape  Width 

25.4 -rO -0.10 

1.000  -rO  -0.004 

Tape  Thickness 

Base  Material 

0.025 

0.0010 

Nominal^ 

Oxide  Thickness 

0.005 

0.0002 

Nominal 

Tape  Length  by  Ree 

Diameters  (reels  with  76  mm  (3  in.)  center  hole) 

Reel  Diameter 

Nominal  Tape  Length 

Minimum  True  Length^^^ 

266  mm  (10.5  in.) 

1100  m  (3600  ft) 

1105  m  (3625  ft) 

It  It  It  It 

1400  m  (4600  ft) 

1410  m  (4625  ft) 

356  mm  (14.0  in.) 

2200  m  (7200  ft) 

2204  m  (7230  ft) 

It  It  It  It 

2800  m  (9200  ft) 

2815  m  (9235  ft) 

381  mm  (15.0  in.) 

3290  m  (10,800  ft) 

3303  m  (10,835  ft) 

408  mm  (16.0  in.) 

3800  m  (12,500  ft) 

3822  m  (12,540  ft) 

Notes: 

1 .  Actual  tape  base  material  thickness  slightly  less  because  of  manufacturing 
conventions. 

2.  Original  dimensions  are  in  feet.  Metric  conversions  are  rounded  for  convenience. 

3.  Tape-to-flange  radial  clearance  (E-value)  is  3.18  mm  (0.125  in.). 

25.2.  Environmental  Conditions 

The  tape  shall  be  able  to  withstand,  with  no  physical  damage  or  performance  degradation, 
any  natural  combination  of  operating  or  non-operating  conditions  as  defined  in  subparagraphs 
25.2.1  and  25.2.2  immediately  below. 

25.2. 1 .  Tape  Storing  Conditions 

Magnetic  tape  is  subject  to  deterioration  at  temperature  and  humidity  extremes.  In  some 
cases,  the  damage  is  reversible,  but  irreversible  damage  may  occur,  especially  with  long-term 
storage  in  unfavorable  conditions. 

25.2.2.  Operating  Environment 

Table  A.2-18  depicts  recommended  limits. 


Table  A.2-18.  Environment  Recommended  Limits 

Condition 

Range 

Temperature 

4  to  30°C  (40  to  85°F) 

Humidity 

20  to  60  percent  relative  humidity  (RH)  non-condensing 

Pressure 

Normal  ground  or  aircraft  operating  altitude  pressures. 

For  very  high  altitudes,  tape  users  should  consult  with 

A.2-44 


Telemetry  Standards,  IRIG  Standard  106-17  Annex  A. 2,  May  2017 


manufacturers  to  determine  if  tape  and  recorder 
compatibility  is  affected  by  low  atmospheric  pressure. 


NOT^ 

1.  Binder/oxide  system  tends  to  become  sticky  and  unusable  above  50°C 
(125°F). 

2.  In  low  humidity,  tape  binder  and  oxide  system  tends  to  dry  out,  and  oxide 
and  binder  adhesion  can  be  unsatisfactory.  Brown  stains  on  heads  may  appear 
below  40  percent  RH. 

3.  In  high  humidity,  abrasivity  is  increased  and  other  performance  problems 
may  arise. 

25.2.3.  Non-operating  Environment 

Temperature  and  Relative  Humidity: 

Short  Term:  0  to  45°C  (32  to  1 15°F)  and  10  to  70  percent  RH  non-condensing 

Long  Term:  1  to  30°C  (33  to  85°F)  and  30  to  60  percent  RH  non-condensing 

not^ 

Experience  has  shown  that  with  long  exposure  to  temperatures  below 
freezing,  lubricants  and  plasticizers  tend  to  migrate  out  of  the  oxide  coating 
thereby  resulting  in  poor  lubrication  and  gummy  surface  deposits. 

25.3.  Other  Characteristics 

Storage  life,  bi-directional  performance,  frictional  vibration,  and  scatterwind 
characteristics  shall  conform  to  Federal  Specification  W-T-1553  unless  otherwise  specified  by 
the  tape  user  at  the  time  of  purchase. 

26.  Physical  Characteristics  of  Instrumentation  Tapes  and  Reels 

As  specified  in  Federal  Specifications  W-T-1553B,  W-T-1553/1-4,^  and  W-R-175. 

27.  Instrumentation  Tape  Magnetic  and  Electrical  Characteristics 

The  following  subparagraphs  describe  required  magnetic  and  electrical  tape 
characteristics. 


^  General  Services  Administration.  “Tape,  Instrumentation  Recording,  Magnetic  Oxide-Coated,  345  Oersteds 
Coercivity,  5  Dropouts  per  100  Foot...”  Federal  Specification  W-T-1553/1.  12  August  1996.  Canceled  with  no 
replacement.  -General  Services  Administration.  “Tape,  Instrumentation  Recording,  Magnetic  Oxide-Coated,  345 
Oersteds  Coercivity,  4  Dropouts  per  100  Foot...”  Federal  Specification  W-T-1553/2.  12  August  1996.  Canceled 
with  no  replacement.  -General  Services  Administration.  “Tape,  Instrumentation  Recording,  Magnetic  Oxide- 
Coated,  700  Oersteds  Coercivity,  4  Dropouts  Per  100  Foot...”  Federal  Specification  W-T-1553/3.  12  August  1996. 
Canceled  with  no  replacement.  -General  Services  Administration.  “Tape,  Instrumentation  Recording,  Magnetic 
Oxide-Coated,  800  Oersteds  Coercivity,  2  Dropouts  Per  100  Foot...”  Federal  Specification  W-T-1553/4.  12 
August  1996.  Canceled  with  no  replacement.  Retrieved  3  June  2015.  All  W-T-1553  documents  available  at 
http://quicksearch.dla.mil/qsSearch.aspx. 
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27.1.  Bias  Level 

The  bias  level  (see  bias  level  definition  in  Section  23)  required  by  the  magnetic  tape  shall 
not  differ  from  the  bias  level  requirements  of  the  reference  tape  by  more  than  the  amount 
specified  by  the  tape  user.  The  test  procedure  outlined  in  Subparagraph  5.3.8. 1,  Bias  Level, 
Volume  III  of  RCC  Document  118  shall  be  used  to  determine  compliance  with  this  requirement. 

27.2.  Record  Level 

The  record  level  (see  record  level  definition  in  Section  23)  required  by  the  magnetic  tape 
shall  not  differ  from  the  record  level  requirements  of  the  reference  tape  by  more  than  the  amount 
specified  by  the  tape  user.  The  test  procedure  outlined  in  Subparagraph  5. 3. 8. 2,  Record  Level, 
Volume  III  of  RCC  Document  118  shall  be  used  to  determine  compliance  with  this  requirement. 

27.3.  Wavelength  Response 

The  output  of  the  magnetic  tape,  measured  at  the  wavelength  values  listed  in  Table 
A. 2-19,  shall  not  differ  from  the  output  of  the  reference  tape  by  more  than  the  amounts  specified 
by  the  tape  user.  Wavelength  response  requirements  shall  be  specified  in  terms  of  output  after 
having  normalized  the  output  to  zero  decibels  at  the  0.1  UBE  wavelength.  The  test  procedure 
outlined  in  Subparagraph  5.3.9,  Wavelength  Response  and  Output  at  0.1  Upper  Band  Edge 
Wavelength,  Volume  III  of  RCC  Document  118  shall  be  used  to  determine  compliance  with  this 
requirement  (see  Table  A. 2-15). 


Table  A.2-19.  Measurement  Wavelengths 

High-Resolution  and  HDD  Tape 

High-Energy  Tape 

(pm) 

(mils) 

(pm) 

(mils) 

3810.00 

(150.000) 

254.00 

(10.000) 

254.00 

(10.000) 

25.40 

(1.000) 

25.40 

(1.000) 

12.70 

(0.500) 

6.35 

(0.250) 

6.35 

(0.250) 

3.18 

(0.125) 

3.18 

(0.125) 

2.54 

(0.100) 

2.54 

(0.100) 

2.03 

(0.080) 

1.52 

(0.060) 

1.52 

(0.060) 

1.02 

(0.040) 

0.76 

(0.030) 

27.4.  Output  at  0.1  UBE  Wavelength 

The  wavelength  output  of  the  magnetic  tape  shall  not  differ  from  the  0. 1  UBE 
wavelength  of  the  reference  tape  by  more  than  the  amount  specified  by  the  tape  user.  The  test 
procedure  outlined  in  Subparagraph  5.3.9,  Wavelength  Response  and  Output  at  0.1  Upper  Band 
Edge  Wavelength,  Volume  III  of  RCC  Document  118  shall  be  used  to  determine  compliance 
with  this  requirement. 
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27.5.  Short  Wavelength  Output  Uniformity 

The  short  wavelength  output  of  the  magnetic  tape  shall  be  consistently  uniform  so  that  a 
signal  recorded  and  reproduced  throughout  the  working  tape  length  in  either  direction  of 
longitudinal  tape  motion  shall  remain  free  from  long-term  amplitude  variation  to  the  extent 
specified  by  the  tape  user.  The  test  procedure  outlined  in  Subparagraph  5.3.10,  Short 
Wavelength  Output  Uniformity,  Volume  III  of  RCC  Document  118  shall  be  used  to  determine 
compliance  with  this  requirement. 


27.6.  Dropouts 


The  instantaneous  non- uniformity  (dropout)  output  of  a  recorded  signal,  caused  by  the 
magnetic  tape,  shall  not  exceed  the  center-track  and  edge-track  limits  specified  by  the  tape  user 
on  the  basis  of  dropouts  per  30.48  m  (100  ft.)  of  nominal  working  tape  length.  The  nominal 
dropout  count  shall  be  determined  by  totaling  all  the  dropouts  per  track  over  the  working  tape 
length  and  dividing  by  the  total  number  of  30.48  m  (100  ft.)  intervals  tested. 


A  second  method  of  specifying  the  allowable  dropout  count  is  to  specify  the  maximum 
number  per  track  for  each  30.48  m  (100  ft.)  interval  tested.  This  method  may  be  preferred  if 
critical  data  is  recorded  in  specific  areas  of  the  working  tape  length,  but  a  specified  number  of 
dropouts  per  hundred  feet  greater  than  the  average  values  may  be  expected. 


NOTE 


Dropout  test  results  are  very  dependent  on  the  tape  transport  used  for  the  test 
and  will  vary  from  run  to  run  on  a  given  transport.  Edge  tracks  tend  to 
contain  more  dropouts  than  the  center  tracks,  and  more  dropouts  are  allowed 
on  the  edge  tracks.  Refer  to  Table  A. 2-14. 


For  HR  tapes,  a  dropout  is  defined  as  a  6  dB  reduction  in  amplitude  for  a  period  of 
5  microseconds  or  more  of  a  1  MHz  sine-wave  signal  recorded  and  reproduced  at  a  tape  speed  of 
3048  mm/s  (120).  Signal  losses  of  6  dB  or  more  which  exceed  the  5  microsecond  time  period 
shall  constitute  a  dropout  count  for  each  5  microsecond  time  period  occurring  in  the  given  signal 
loss.  The  definitions  for  center  tracks  and  edge  tracks  are  in  Section  23.  The  test  procedure 
outlined  in  Subparagraph  5.3. 1 1,  Volume  III  of  RCC  Document  1 18  shall  be  used  to  determine 
compliance  with  this  requirement. 

For  HDD  tapes,  a  dropout  is  defined  as  a  10  dB  or  greater  reduction  in  amplitude  for  a 
period  of  1  microsecond  or  more  of  a  square-wave  test  signal  of  maximum  density  recorded  and 
reproduced  at  3048  mm/s  or  1524  mm/s  (120  in/s  or  60  in/s).  On  at  least  every  other  track  (7 
tracks  of  the  odd  head  on  a  28-track  head  assembly  (alternatively,  every  other  track  of  the  even 
head)  record  and  reproduce  a  square- wave  test  signal  of  2  MHz  at  3048  mm/s  (120  in/s)  or 
1  MHz  at  1524  mm/s  (60  in/s).  The  record  level  shall  be  set  slightly  above  saturation  by 
adjusting  the  record  current  to  produce  maximum  reproduce  output  and  increasing  the  record 
current  until  the  output  signal  is  reduced  to  90  percent  of  maximum.  For  playback,  a  reproduce 
amplifier  and  a  threshold  detector  shall  be  used.  The  signal-to-noise  ratio  of  the  test  signal  at  the 
input  to  the  threshold  detector  shall  be  at  least  25  dB,  and  the  detector  shall  detect  any  signal  loss 
of  10  dB  or  more  below  reference  level.  The  reference  level  shall  be  established  by  averaging 
the  test  signal  output  level  over  a  10  m  (30.8  ft.)  nominal  tape  length  in  the  vicinity  of  a  dropout. 

For  each  of  the  seven  tracks  tested,  the  accumulated  duration  in  microseconds  of  detected 
dropout  events  shall  be  displayed  and  used  to  directly  display  the  dropout  rate  for  each  track 
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scaled  appropriately  for  the  tape  working  length.  Signal  losses  of  10  dB  or  more  which  exceed 
the  1  microsecond  time  period  shall  constitute  a  dropout  count  for  each  microsecond  time  period 
occurring  in  the  given  signal  loss. 

For  high-energy  tapes,  a  dropout  is  defined  as  for  high-resolution  tapes  except  that  a 
2-MHz  signal  is  used. 

27.7.  Durability 

The  magnetic  tape  shall  resist  deterioration  in  magnetic  and  electrical  performance 
because  of  wear  to  the  coating  surface.  Signal  losses,  as  defined  below,  caused  by  surface  wear 
shall  not  occur  in  excess  of  the  per-pass  limits  specified  in  Table  A.2-16  for  the  first  35  passes. 

Signal  losses  in  excess  of  those  limits  specified  above  shall  not  occur  during  either  a 
record,  record  and  reproduce  or  uninterrupted  reproduce  pass  of  the  working  tape  length.  Signal 
loss  is  a  reduction  in  signal  amplitude  of  3  dB  or  greater  for  a  period  of  3  through  10  seconds  of 
a  recorded  and  reproduced  short  wavelength  signal.  Where  a  continuous  loss  of  signal  of  3  dB  or 
greater  exceeds  the  10-second  period,  a  signal  loss  count  shall  be  required  for  every  sequential 
10-second  time  period  occurring  in  the  given  signal  loss.  The  test  procedure  outlined  in 
Subparagraph  5.3.12,  Durability,  Volume  III  of  RCC  Document  118  shall  be  used  to  determine 
compliance  with  this  requirement. 

27.8.  Modulation  Noise 

The  amplitude  modulation  superimposed  upon  a  recorded  and  reproduced  signal  by  the 
magnetic  tape  shall  not  exceed  the  limits  specified  by  the  tape  user.  The  test  procedure  outlined 
in  Subparagraph  5.3. 13,  Modulation  Noise,  Volume  III  of  RCC  Document  1 18  shall  be  used  to 
determine  compliance  with  this  requirement. 

27.9.  Layer-to-Layer  Signal  Transfer 

A  signal  resulting  from  layer-to-layer  signal  transfer  shall  be  reduced  in  amplitude  from 
the  original  signal  a  minimum  of  40  dB  for  25.4  pm  (1.0  mil)  tape  and  46  dB  for  38.1  pm  (1.5 
mils)  tape.  The  test  procedure  outlined  in  Subparagraph  5.3.14,  Layer-to-Layer  Signal  Transfer, 
Volume  III  of  RCC  Document  1 18  shall  be  used  to  determine  compliance  with  this  requirement. 

27.10.  Erasure  Ease 

Eor  HR  and  HDDR  tapes,  an  erase  field  of  79.58  kiloamps  per  meter  (kA/m)  (1000 
oersteds)  shall  effect  at  least  a  60  dB  reduction  in  output  amplitude  of  a  previously  recorded  25.4 
pm  (1.0  mil)  wavelength  signal.  For  HE  tapes,  an  erase  field  of  160  kA/m  (2000  oersteds)  shall 
effect  at  least  a  60  dB  reduction  of  a  previously  recorded  25.4  pm  (1.0  mil)  wavelength  signal. 
The  test  procedure  outlined  in  Subparagraph  5.3.15,  Volume  III  of  RCC  Document  1 18  shall  be 
used  to  determine  compliance  with  this  requirement. 

27.11.  Suggested  Tape  Requirement  Eimits 

Table  A. 2- 14  lists  some  suggested  limits  to  be  used  for  instrumentation  tape. 
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ADARIO 

Acronyms 

Analog/Digital  Adaptable  Recorder  Input/Output 

BCD 

binary  coded  decimal 

BM 

block  marker 

BMD 

block  marker  divisor 

BW 

bandwidth 

Hz 

hertz 

LIFO 

last-in-first-out 

LSB 

least  significant  bit 

Mbps 

megabits  per  second 

MHz 

megahertz 

MSB 

most  significant  bit 

MC 

master  clock 

PW 

partial  word 

TBD 

to  be  defined 
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ANNEX  A.3 

ADARIO  Data  Block  Field  Definitions 

1.  Data  Block  Format  and  Timing 

The  details  of  the  Analog/Digital  Adaptable  Reeorder  Input/Output  (ADARIO)  data 
bloek  format  are  provided  in  Figure  A.3-1  and  in  the  ADARIO  data  format  field  summary.  As 
shown  in  Figure  A.3-1,  the  eight  session  header  words  are  the  first  eight  words  of  the  bloek.  The 
ehannel  paeket  for  the  highest  priority  (priority  1)  ehannel  is  next,  followed  by  the  next  lower 
priority  ehannel  paeket  (priority  2).  Following  the  lowest  priority  ehannel,  fill  data  eonsisting  of 
all  ones  are  inserted  as  required  eompleting  the  2048-word  data  bloek. 

Within  the  ehannel  paeket,  the  first  five  words  are  the  ehannel  header  words  ineluding  the 
partial  word  (PW).  Following  the  ehannel  header  is  the  variable  size  ehannel  data  field.  The 
channel  data  are  organized  in  a  last-in-first-out  (LIFO)  fashion.  The  first  samples  acquired  in  the 
block  time  interval  appear  in  the  last  data  word  of  the  channel  packet.  The  sample  data  are 
formatted  into  the  24-bit  data  word  such  that  the  first  sample  occupies  the  most  significant  bits 
(MSBs)  of  the  word.  The  next  sample  is  formatted  into  the  next  available  MSBs  and  so  on  until 
the  word  is  full.  As  an  example,  data  formatted  into  8-bit  samples  is  shown  in  Figure  A. 3-2. 

In  cases  where  the  24-bit  data  word  is  not  a  multiple  of  the  sample  size,  the  sample 
boundaries  do  not  align  with  the  data  words.  In  these  cases,  the  samples  at  the  word  boundaries 
are  divided  into  two  words.  The  MSBs  of  the  sample  appear  in  least  significant  bits  (LSBs)  of 
the  first  buffered  word  and  the  LSBs  of  the  sample  appear  in  the  MSBs  of  the  next  buffered 
word.  Since  the  channel  data  appears  in  a  LIFO  fashion  in  the  ADARIO  data  block,  the  MSBs 
of  the  divided  sample  will  occur  in  the  data  word  following  the  word  containing  LSBs  of  the 
sample.  Figure  A. 3-3  depicts  ADARIO  timings. 
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Figure  A.3-1.  ADARIO  Data  Format 


A.3-2 


Telemetry  Standards,  RCC  Standard  106-17  Annex  A. 3,  July  2017 


Figure  A. 3-2.  ADARIO  Data  Blocks 
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Figure  A .  3  -  3 .  AD ARIO  T iming 


2.  ADARIO  Data  Format  Field  Definitions  Summary 

2.1.  Block  Length 

Block  length  is  defined  with  2048  24-bit  words,  fixed  length 


2.2.  Session  Header 


Session  header  information  is  provided  by  8  words  in  a  fixed  format 


SHWO 

(bits  23  to  0) 

SHWl 

(bits  23  to  19) 

(bits  18  to  0) 

SHW2 

(bits  23  to  0) 

SHW3 

(bits  23  to  0) 

SYNC  Field,  bits  0-23  of  the  29-bit  block  sync.  The  LSBs  of  the 
block  sync  are  36E19C  and  are  contained  here. 

SYNC  Field,  bits  24-28  of  the  29-bit  block  sync.  The  MSBs  of  the 
block  sync  are  01001  and  are  contained  here.  The  29-bit  block 
sync  is  fixed  for  all  ADARIO  configurations  and  chosen  for 
minimal  data  cross  correlation. 

MC  -  Master  clock,  a  19-bit  binary  value  in  units  of  250  hertz 
(Hz).  MC  is  the  clock  frequency  used  to  derive  session  and  per 
channel  parameters. 

BLK#  -  ADARIO  data  block  number,  a  24-bit  binary  value.  BLK# 
is  to  zero  at  the  start  of  each  session  and  counts  up  consecutively. 
Rollover  is  allowed. 

YYMMDD  -  Time  code  field,  a  binary  coded  decimal  (BCD) 
representation  of  the  year  (YY),  month  (MM),  and  day  (DD). 
YYMMDD  time  code  field  is  updated  during  the  record  process 
once  per  second. 
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SHW4  (bits  23  to  0) 

SHW5  (bits  23  to  0) 

SHW6  (bit  23) 

(bits  22  to  19) 

(bits  17  to  18) 
(bits  16  to  0) 

SHW7  (bits  23  to  16) 

(bits  15  to  6) 
(bits  5  to  0) 


HHMMSS  -  Time  code  field,  a  BCD  representation  of  the  hour 
(HH),  minute  (MM),  and  second  (SS).  The  HHMMSS  Time  Code 
Field  is  updated  during  the  record  process  once  per  second. 

BMD  -  Block  marker  divisor,  a  24-bit  binary  value.  BMD  is 
established  so  that  the  block  marker  (BM)  frequency  may  be 
derived  from  MC  by  BM  =  MC/BMD 

MCS  -  Master  clock  source,  a  1-bit  flag. 

1  =  MC  was  generated  internally. 

0  =  MC  was  provided  from  an  external  source. 

Q  -  Number  of  active  channels  minus  one,  a  4-bit  binary  value. 

For  example,  0  indicates  that  one  channel  is  active. 

SPl  -  Spare  field  1,  a  2-bit  field.  It  is  set  to  zero. 

SST  -  Session  start  time,  a  17-bit  binary  value  in  units  of  seconds. 
The  integer  number  of  seconds  represents  the  session  start  time  of 
day  in  seconds,  where  midnight  starts  with  zero. 

User  defined,  an  8-bit  field.  May  be  input  by  the  user  at  any  time 
during  a  recording  session.  The  interpretation  of  this  bit  field  is 
left  to  the  user. 

SP2  -  Spare  field  2,  a  10-bit  field.  It  is  set  to  zero. 

VR  -  Version  number,  a  6-bit  binary  value.  Each  update  of  the 
ADARIO  format  will  be  identified  by  a  unique  version  number. 


2.3.  Channel  ‘n’  Header 

All  channel  headers  contain  five  24-bit  ADARIO  words  with  the  following  fixed  format. 
The  first  logical  channel,  n=l,  has  the  highest  priority  and  its  channel  packet  starts  in  the  ninth 
word  of  the  data  block.  Each  active  channel  is  represented  by  a  channel  packet  that  is  present  in 
the  data  block.  The  logical  channel  number,  n,  represents  the  relative  priority  of  the  channel  and 
the  order  in  which  it  appears  in  the  data  block. 

CnHWO  (bits  23  to  20)  CH#  -  Physical  channel  number,  a  4-bit  binary  value.  0  to  15 

represents  the  physical  location  of  the  channel  electronics  in  the 
ADARIO  hardware.  The  user  sees  those  locations  labeled  from  1 
to  16. 

(bits  19  to  16)  FMT  -  Eormat  code  for  the  channel  data  word,  a  4-bit  binary  value. 

The  format  code  is  used  to  define  the  size  of  the  user  data  word  by 
means  of  Table  A. 3-1. 


Table  A.3-1.  User  Data  Word  Size 

15=24  bits 

7=8  bits 

14=22  bits 

6=7  bits 

13=20  bits 

5=6  bits 

12=18  bits 

4=5  bits 
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11=16  bits 

3=4  bits 

10=14  bits 

2=3  bits 

9=12  bits 

1=2  bits 

8=10  bits 

0=1  bit 

(bits  15  to  5) 


(bits  4  to  0) 


CnHWl  (bit  23) 


(bit  22) 


(bit  21) 


(bit  20) 


(bit  19) 


WC  -  Word  count,  an  1 1-bit  binary  value.  WC  is  the  number  of 
full  channel  data  words  that  should  be  in  the  nth  channel  packet. 
WC  may  range  from  0  to  2040.  A  WC  greater  than  the  number  of 
actual  words  in  channel  packet  indicates  a  data  rate  overflow, 
which  would  occur  when  a  low -priority  channel  is  not  provided 
sufficient  space  in  the  fixed  length  data  block  as  a  result  of  an 
uncontrolled  data  rate  in  a  higher  priority  channel. 

PWS  -  Partial  word  status,  a  5-bit  binary  value.  PWS  is  related  to 
the  number  of  samples  in  the  partial  word  and  may  range  from  0  to 
23.  PWS  shall  be  computed  as  follows: 

If  the  number  of  full  samples  in  the  partial  word  equals 
zero,  then  PWS  =  0. 

If  the  number  of  full  samples  in  the  partial  word  does  not 
equal  zero,  then  PWS  =  Round  Up  [Unused  bits  In 
PW/Channel  Sample  Size]. 

IE  -  Channel  clock  source,  a  1-bit  flag. 

1  =  The  channel  clock  was  generated  internally. 

0  =  The  channel  clock  was  provided  from  an  external 
source. 

DA  -  Data  type,  a  1-bit  flag. 

1  =  The  channel  is  operated  as  a  digital  channel. 

0  =  The  channel  is  operated  as  an  analog  channel. 

ROVR  -  Rate  overrun  in  previous  block,  a  1-bit  flag. 

1  =  The  nth  channel  packet  in  the  previous  data  block 
experienced  an  overrun. 

0  =  The  nth  channel  packet  in  the  previous  data  block  did 
not  experience  an  overrun. 

AOVR  -  Analog  A/D  overrange  in  current  block  a  1-bit  flag. 

1  =  The  nth  channel  in  the  current  data  block  experienced 
an  analog-to-digital  conversion  overrange  condition. 

0  =  The  nth  channel  in  the  current  data  block  did  not 
experience  an  analog-to-digital  conversion  overrange 
condition. 

NSIB  -  No  samples  in  current  block,  a  1-bit  flag. 
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1  =  TRUE,  there  are  no  samples  for  the  nth  channel  in  the 
current  block. 

0  =  False,  there  are  samples  for  the  nth  channel  in  the 
current  block. 

(bits  18  to  0)  RATE  -  Channel  sample  rate  indicator,  19-bit  binary  value.  The 
interpretation  of  the  rate  value  depends  on  the  condition  of  IE,  the 
channel  clock  source  flag. 

If  IE  =  1,  then  the  value  of  rate  is  carried  by  the  16  ESBs  of 
the  rate  field.  Using  rate,  the  frequency  of  the  internal 
channel  clock  can  be  found  by  internal  sample  clock  = 
(MC/RATE)  -1. 

IF  IE  =  0,  then  rate  is  a  19-bit  binary  value  in  units  of  250 
Hz,  which  equals  the  frequency  of  the  external  channel 
clock  as  provided  by  the  user  at  the  time  of  the  setup. 


NOTE 


The  definitions  that  are  marked  with  an  asterisk  apply  to  analog 
channels  and  to  particular  hardware  implementations  of  ADARIO. 
For  the  purposes  of  this  standard,  these  fields  are  not  used. 


*CnWD2  (bits  23  to  16) 

(bits  15  to  0) 

*CnWD3  (bits  23  to  22) 

(bits  21  to  17) 

(bit  16) 

(bits  15  to  8) 


FB  -  Filter  bandwidth  (BW),  an  8-bit  binary  value.  The  formula 
for  the  BW  of  the  anti-aliasing  filter  used  in  an  analog  channel 
incorporates  FB  as  BW  =  (FB/2)  • 

TD  -  Time  Delay  to  first  sample,  a  16-bit  binary  value.  TD  is  a 
measure  of  the  time  delay  from  the  block  marker,  BM,  to  the  first 
sample  arriving  at  the  nth  channel  during  the  current  data  block 
interval.  TD  is  expressed  as  the  number  of  master  clock,  MC, 
periods  minus  one. 

FR  -  Filter  Range,  a  2-bit  binary  value.  The  formula  for  the  BW  of 
the  anti-aliasing  filter  used  in  an  analog  channel  corporates  FR  as 
BW  =  (FB/2)  • 

ATTEN  -  Attenuation,  a  5-bit  binary  value.  ATTEN  represents  the 
setting  of  the  input  attenuator  (or  gain)  on  the  nth  channel  at  the 
time  that  the  record  was  formed  0  =  -15dB  and  31  =  -i-16dB  with 
intermediate  settings  expressed  in  one  dB  steps. 

DC  AC  -  Analog  signal  coupling,  a  1-bit  flag. 

1  =  The  channel  is  operated  with  dc  coupling  at  the  input. 

0  =  The  channel  is  operated  with  ac  coupling  at  the  input. 

CHP  -  Channel  parameter  field,  an  8-bit  field.  The  interpretation 
of  the  CHP  field  depends  upon  the  card  type  with  which  it  is 
associated,  as  defined  by  the  CHT  field.  Each  card  type 
established  by  the  CHT  field,  as  part  of  its  definition,  shall  specify 
the  form  and  interpretation  of  the  CHP  field.  To  date,  four  input 
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card  types  have  been  established.  The  CHP  fields  are  defined  as 
follows: 


*  ForCHT=0 

(bits  15  to  8) 


*  ForCHT=l 

(bits  15  to  8) 


*  ForCHT=2 

(bits  15  to  8) 


For  CHT=3 

(bits  15  to  12) 

(bits  11  to  8) 

(bits  7  to  6) 
(bits  5  to  0) 


* 

* 

* 

* 


* 


remain  undefined  for  the  present  analog  single  channel 
implementation  except  that  the  present  hardware  implementation 
expects  an  all  zero  field.  Would  be  subject  to  future  definition  as 
long  as  all  the  zero  fill  is  set  aside. 


remain  unused  for  the  present  digital  single  channel 
implementations  except  that  the  present  hardware  implementation 
expects  an  all  zero  field.  Would  be  subject  to  future  definition  as 
long  as  the  all  zero  fill  is  set  aside. 


remain  unused  for  the  present  dual-purpose  channel 
implementations  except  that  the  present  hardware  implementation 
expects  an  all  zero  field.  Would  be  subject  to  future  definition  as 
long  as  the  all  zero  fill  is  set  aside. 


establish  the  number  of  subchannels  that  are  multiplexed  into  the 
multichannel  data  carried  by  the  nth  channel. 

identify  the  subchannel  number  of  the  first  sample  contained  in  the 
nth  channel  packet  of  the  data  block. 

SP3  -  Spare  field  3,  a  2-bit  field.  It  is  set  to  zero. 

CHT  -  Channel  type,  a  6-bit  field.  Defines  the  type  of  channel 
through  which  input  data  was  acquired.  Additional  channel  types 
to  be  defined  (TBD)  by  future  users  and  developers. 

CHT=0  Single  channel  analog  input 

CHT=1  Single  channel  digital  input 

CHT=2  Single  channel,  dual-purpose,  analog  or  digital  input 

CHT=3  Multichannel  analog  input  capable  of  multiplexing  up  to 
16  analog  inputs 

CHT=4  Single  channel  digital  input,  dual  channel  analog  input 
(stereo) 

“L”  channel  on  bits  15  to  8  of  the  sample  word 
“R”  channel  on  bits  7  to  0  of  the  sample  word 

CHT=5  Single  channel,  triple-purpose,  analog,  digital,  submux, 
formatted  input 
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CnWD4  (bits  23  to  0) 


Fill  (bits  23  to  0) 


PW  -  Partial  word,  A  24-bit  field.  PW  contains  the  last  samples  of 
the  data  block.  The  most  significant  bits  of  word  contain  the  first 
sample,  followed  by  the  next  sample  in  the  next  most  significant 
bits.  The  number  of  samples  in  the  PW  is  defined  in  the  PWS 
field.  The  unused  bits  are  not  intentionally  set  and  so  contain 
random  data. 

Fill  -  Fill  Words  consisting  of  all  ones  binary,  used  for  fixed  rate 
aggregate.  Fill  words  may  be  omitted  when  variable  rate  aggregate 
can  be  accommodated  resulting  in  variable  length  blocks  of  up  to 
2048,  24-bit  words. 


3.  Submux  Data  Format  Field  Definitions 

The  details  of  the  submux  data  format  are  shown  in  Table  A. 3-2  and  Table  A. 3-3  and 
defined  in  Section  4.  Figure  A. 3-4  shows  a  typical  primary  channel  aggregate  data  content  for 
fixed  and  variable  rate  channel.  Submux  data  format  is  based  on  the  sequential  collection  of  the 
individual  channel  data  blocks.  Each  channel  data  block  is  the  sequential  collection  of  presented 
input  samples  in  a  fixed  period  of  time.  This  sequential  collection  results  in  a  variable  length, 
fixed  rate,  and  channel  data  blocks.  To  accommodate  fixed  rate  channels,  fill  is  also  defined. 
The  aggregate  data  stream  is  composed  of  a  block  sync  timing  channel,  followed  by  sequential 
channel  data  blocks,  if  enabled,  followed  by  fill,  if  required,  at  fixed  block  rate. 
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Table  A.3-2.  Submux  Data  Format 

General  Form 

HWl 

HW2 

HW3 

15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

CHNID 

CHT 

FMT 

STl 

ST2 

ST3 

ST4 

FE 

Time  Delay  or  Sample  Period 

Frame  Sync 

HWl 

HW2 

HW3 

CHN  ID  =  IF 

CHT  =  0 

Sync  1  =  F8C7  hex  (full  word) 

Sync  2  =  BFIE  hex 

BRC 

Fill 

AGE 

PCRE 

ST3 

ST4 

1 

dme  Tag 

HWl 

HW2 

HW3 

CHN  ID  =  0  to  30 

CHT  =  0 

MSB  Days  (BCD) 

Days  FSB 

Hours  (BCD)  FSB 

Minutes  (BCD)  FSB 

Seconds  (BCD)  FSB 

Fractional  Seconds  FSB 

Annotation 

"ext 

HWl 

HW2 

HW3 

DWl 

DWn 

CHN  ID  =  0  to  30 

CHT=  1 

FMT  =  7 

NC 

OVR 

PE 

OF 

Bit_Count 

Block  Count 

MSB  Character  FSB 

MSB  2"‘^  Character  FSB 

MSB  Fast  Character  FSB 

Undefined  if  not  last 

Digital  Serial  External  Clock 

HWl 

HW2 

HW3 

DWl 

DWn 

Digital  Serial  External  Clock 

CHN  ID  =  0  to  30 

CHT  =  2 

FMT  =  0 

NSIB 

OVR 

ST3 

ST4 

Bit_Count  =  F 

FE=0 

Time  Delay 

DSi 

DSi 

DSa 

DS4 

DSs 

DSe 

DS? 

DSs 

DS9 

DSl 

DSl 

DSl 

DSl 

DSl 

DSl 

DSl 

DSl-1 

DSl 

Undefined  if  not  last 
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Table  A.3-3.  Submux  Data  Format  (Continuation) 

Digital  Serial  Internal  Clock 

HWl 

HW2 

HW3 

DWl 

DWn 

15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

CHN  ID  =  0  to  30 

CHT  =  2 

EMT  =  0 

0 

0 

ST3 

ST4 

BIT_COUNT  =  L 

I/R=l 

SAMPLE  PE 

RIOD 

DSi 

DSi 

DS3 

DS4 

DSs 

DSe 

DS? 

DSs 

CSi 

CS2 

CS3 

CS4 

CSs 

CSe 

CS7 

CSs 

DSl-7 

DSl-6 

DSl-5 

DSl-4 

DSl-3 

DSl-2 

DSl-1 

DSl 

CSl-7 

CSl-6 

CSl-5 

CSl-4 

CSl-3 

CSl-2 

CSl-1 

CSl 

Digital  Parallel  External  Clock 

HWl 

HW2 

HW3 

DWl 

DWn 

15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

CHN  ID  =  0  to  30 

CHT  =  3 

EMT=0  to  15  (shown  =6) 

NSIB 

OVR 

ST3 

ST4 

BIT_COUNT  =  L 

I/R=0 

TIME  DELAY 

MSB  1  samnle 

MSB  2"‘^  samnle 

3rd  samnle 

MSB  Last  samnle  LSB=bit  L  UNDEEINED  if  not  last 

Analog  Wide  Band 

HWl 

HW2 

HW3 

DWl 

DWn 

15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

CHN  ID  =  0  to  30 

CHT  =  4 

EMT=0  to  15  (shown  =7) 

AOR 

ST2 

ST3 

ST4 

BIT_COUNT  =  L 

I/R=l 

SAMPLE  PERIOD 

MSB  R‘  samnle 

MSB  samnle 

MSB  Last  SAMPLE  LSB=bit  L 

UNDEEINED  if  not  last 

Analog  Stereo  Le 

Ft  and  Right 

HWl 

HW2 

HW3 

DWl 

DWn 

15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

CHN  ID  =  0  to  30 

CHT  =  5 

EMT=0  to  15  (shown  =7) 

EAOR 

RAOR  ST3 

ST4 

BIT_COUNT  =  L 

I/E=l 

ENL 

ENR 

SAMPEE  PERIOD 

MSB  L‘ samnle  “L” 

MSB  1  samnle  “R” 

MSB  East  samnle 

UNDEEINED  if  not  last 

Fill 

FW 

Eill  Word  =  FREE  hex 
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Fixed  Rate  Channel 

Variable  Rate  Channel 

Frame  1 

Block 

Frame  1 

Block 

Sync 

Sync 

CHN#0 

CHN#0 

CHN#1 

CHN#1 

CHN#3 

CHN#3 

CHN#17 

CHN#17 

CHN#18 

CHN#18 

FILL 

Frame  2 

Block 

Frame  2 

Block 

Sync 

Sync 

CHN#0 

CHN#0 

CHN#1 

CHN#1 

CHN#3 

CHN#3 

CHN#17 

CHN#17 

CHN#18 

CHN#18 

FILL 

Figure  A. 3-4.  Submux  Aggregate  Format 


The  channel  data  blocks  are  the  sequential  collection  of  input  samples  bit  packed  into 
sequential  16-bit  words  over  the  block  period  of  time.  The  data  block  is  preceded  by  a  three- 
word  header  that  identifies  the  source  (channel  ID)  of  data,  channel  type  of  processing,  packing 
format  in  the  data  block,  bit  count  length  of  the  valid  data,  and  the  time  delay  between  the  first 
sample  and  the  block  period.  If  data  were  internally  sampled,  the  sample  period  is  defined  with 
the  first  sample  being  coincident  with  the  start  of  block  period.  Channel  type  is  used  to  define 
specific  types  of  channels  that  provide  timing,  annotation,  and  synchronization  functions  that 
may  be  required  by  the  specific  primary  channel  or  may  be  redundant  and  not  required.  Specific 
implementation  of  the  required  channels  may  provide  only  the  required  channels  with  specific 
implementation  constraints  that  limit  the  aggregate  rate  or  the  range  of  any  specific  field. 
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The  submux  format  is  based  on  a  16-megahertz  (MHz)  clock  defining  all  timing.  The 
derived  clock  is  the  16-MHz  clock  divided  in  binary  steps  as  defined  by  that  defines  all 
timing  and  internal  sampling.  Block  period  is  20,160  derived  clock  periods  which  limits  the 
submux  aggregate  to  256  megabits  per  second  (Mbps),  limits  the  maximum  block  rate  to  793.65 
blocks  per  second,  and  in  conjunction  with  a  16-bit  bit  count  field,  limits  the  subchannel 
maximum  data  rate  to  52  Mbps. 

4.  SubMux  Data  Format  Field  Definitions  Summary 

4.1.  Frame  length 

Frame  length  is  variable  or  fixed  with  fill.  Minimum  is  3-word  block  sync  plus  one 
channel  block,  maximum  is  20, 160x1 6-bit  words. 


4.2.  Block  length 

This  field  is  variable  from  3x1 6-bit  words  to  4099x1 6-bit  words  per  channel  data  block. 
The  length  is  specified  by  CHT>0  and  integer  of  (Bit_Count-i-15/16)  and  may  be  limited  by 
implementation. 

4.3.  Block  sync 

This  is  defined  by  Channel  ID  =  31,  3-word  block,  2- word  sync.  The  channel  defines  a 
period  of  20,160  derived  clocks. 


4.4.  General  form 

All  channel  data  blocks  contain  this  information  in  the  3 -word  header. 


HWl  (bits  15  to  11) 
(bits  10  to  8) 


CHN  ID  -  Channel  ID  number.  From  0  to  30  represents  normal 
channel  of  any  type.  CHN  ID  =  31  reserved  for  Block  Sync. 

CHT  -  Channel  type.  From  0  to  7  defines  type  of  processing 
performed  on  the  data  and  the  format  of  header  word  fields. 

CHT  =  0  Timing  channel,  block  sync  or  time  tag,  3-word 
only 

CHT  =  1  Annotation  text  or  block  count,  variable  length 

CHT  =  2  Digital  serial  external  or  internal  clock,  variable 

CHT  =  3  Digital  parallel  external  clock,  variable 

CHT  =  4  Analog  wide  band,  variable 

CHT  =  5  Analog  stereo,  variable 

CHT  =  6  TBD  by  future  implementation 

CHT  =  7  TBD 


HWl 


Variable  length  General  form  with  variable  data  block  length 

(bits  15  to  1 1)  CHN  ID  -  Channel  ID  number.  From  0  to  30  represents  normal 
channel  of  any  type. 

(bits  10  to  8)  CHT  -  Channel  type.  From  1  to  7  defines  type  of  processing 
performed  on  the  data  and  the  format  of  header  word  fields. 
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(bits  7  to  4) 

FMT  -  Format,  defines  the  number  of  bits  minus  one  in  each 
sample.  Data  block  sample  size  (bits)  =  (FMT-i-1).  Range  0  to  15, 
binary  format. 

(bits  3  to  0) 

STl  to  ST4,  status  bits,  define  dynamic  conditions  within  this 
block  period  such  as  over  range. 

HW2 

(bits  15  to  0) 

Bit_Count  defines  the  number  of  valid  data  bits  in  the  data  block 
starting  with  the  most  significant  bit  of  the  first  data  word  DW 1 . 
Variable  word  length  of  the  data  block  is  the  Integer  of 
{(Bit_Count  -1-  15)716}.  Range  0  to  65,535,  binary  format. 

HW3 

(bit  15) 

FE  -  Intemal/external  clock 

(bits  15  to  0) 

Depends  on  CHT  field,  defines  block  count,  time  delay,  or  sample 
period. 

4.5. 

Block  Sync 

The  following  defines  the  start  of  channel  data  blocks  and  start  of  block  period  that  lasts 
for  20,160  derived  clocks. 

HWl 

(bits  15  to  0) 

SYNC  1  =  F8C7  hex,  defines  the  first  sync  word. 

HW2 

(bits  15  to  0) 

SYNC  2  =  BFIE  hex,  defines  the  second  sync  word. 

HW3 

(bits  15  to  13) 

BRC  -  Block  rate  clock,  defines  the  binary  divisor  for  the  16  MHz 
system  clock.  Derived  CEK  =16  MHz  /  2®^*“  MHz.  Block  rate  = 
Derived  CEK  /  20,160  Hz.  Period  =  1  /  Derived  CEK. 

(bit  12) 

EIEE  -  indicates  if  the  primary  channel  requires  fill  for  constant 
rate. 

(bits  1 1  to  4) 

TBD 

(bit  3) 

AOE  -  Aggregate  overrun  error  if  set  indicates  that  the  aggregate 
of  the  enabled  channels  exceeds  the  submux  aggregate  (data 
truncated  to  20,160  words  between  sync). 

(bit  2) 

PCRE  -  Primary  channel  rate  error  if  set  indicates  that  primary 
channel  is  unable  to  maintain  the  aggregate  rate  of  the  submux. 
Excess  blocks  are  truncated. 

(bits  1  to  0) 

ST3,  ST4,  Status  reserved. 

4.6. 

Time  Tag 

The  following  defines  the  time  tag  channel  for  time  stamping  the  frame. 

HWl 

(bits  15  to  11) 

CHN  ID  -  Channel  ID  number.  Erom  0  to  30  represents  normal 
channel. 

(bits  10  to  8) 

CHT  =  0,  Channel  Type  =  0,  Time  Tag  IRIG  Time  code 

processing  and  3-word  format. 
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HW 

(bits  7  to  0) 

DAYS  -  Most  significant  8  bits  of  Time  Code  Days  field.  BCD 
format. 

(bits  15  to  14) 

DAYS  -  Least  significant  2  bits  of  Time  Code  Days  field.  BCD 
format. 

(bits  13  to  8) 

HOURS  -  Time  code  hours,  6-bit  field.  BCD  format. 

HW 

(bits  7  to  0) 

MINUTES  -  Time  code  minutes,  7-bit  field.  BCD  format. 

(bits  15  to  8) 

SECONDS  -  Time  code  seconds,  7-bit  field.  BCD  format. 

(bits  7  to  0) 

ERACTIONAL  SECONDS  -  Time  code  fractional  seconds,  8-bit 
field.  BCD  format. 

4.7. 

Annotation  Text 

The  following  defines  block  count  and  annotation  text  that  pertains  to  the  subchannels  at 
this  time. 

HWl 

(bits  15  to  11) 

CHN  ID  -  Channel  ID  number.  Erom  0  to  30  represents  normal 
channel. 

(bits  10  to  8) 

CHT  =  1,  Channel  Type  =  1,  Block  Count  and  Annotation  Text  if 
any. 

(bits  7  to  4) 

EMT  =  7,  Eormat  =  7,  defines  8  bit  ASCII  character  in  text. 

(bit  3) 

NC  -  No  Characters  (Bit_Count  =  0)  Block  count  only. 

(bits  2  to  0) 

OVR,  PE,  OE  -  Overrun  Parity  and  async  framing  error. 

HW 

(bits  15  to  0) 

Bit_Count  defines  the  number  of  valid  data  bits  in  the  data  block 
starting  with  the  MSB  of  the  first  data  word  DW  1 .  Variable  word 
length  of  the  data  block  is  the  Integer  of  {(Bit_Count  -i-  15)716}. 
Range  0  to  65,535,  binary  format. 

HW 

(bits  15  to  0) 

Block_Count  sequential  block  numbering  with  rollover  at 
maximum.  Range  0  to  65,535,  binary  format. 

DWl 

(bits  15  to  8) 

1st  character  -  first  text  character. 

DW 

(bits  8  or  0) 

Last  character  -  LSB  is  defined  by  the  bit  count. 

4.8. 

Digital  Serial  External  Clock 

Defines  digital  serial  data  such  as  PCM  externally  clocked. 

HWl 

(bits  15  to  11) 

CHN  ID  -  Channel  ID  number.  Erom  0  to  30  represents  normal 
channel. 

(bits  10  to  8) 

CHT  =  2,  Channel  Type  =  2,  digital  serial  or  data  and  clock  over 
sampled  data. 

(bits  7  to  4) 

EMT  =  0  Eormat  =  0,  defines  1-bit  data  samples. 

(bit  3) 

NSIB  -  No  Samples  In  Block  (Bit_Count=0)  header  only. 
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(bit  2) 

OVR  -  Overrun  indicates  that  input  is  clocking  at  faster  than 
specified  rate.  Data  is  truncated  at  specified  bit  rate  (Bit  Count  per 
Block). 

HW 

(bits  15  to  0) 

Bit_Count  -  Defines  the  number  of  valid  data  bits  in  the  data  block 
starting  with  the  most  significant  bit  of  the  first  data  word  DW 1 . 
Variable  word  length  of  the  data  block  is  the  Integer  of 
{(Bit_Count  -1-  15)716} .  Range  0  to  65,535,  binary  format. 

Limited  by  set  maximum  rate. 

HW 

(bit  15  ) 

I/E  =  0  -  Intemal/extemal  clock  flag  indicates  that  external 
clocking  was  used  with  relative  phasing  to  block  as  specified  in 
next  field. 

(bits  14  to  0) 

Time  Delay  -  provides  the  measure  of  time  between  start  of  block 
period  and  the  first  external  clock  in  derived  clock  periods.  Range 
0  to  20,160,  binary  format. 

DWl 

(bit  15) 

DSi  -  first  data  sample  at  the  first  clock  time  in  the  block. 

DWn 

(bit  L) 

DSl  -  last  data  sample  in  this  block  period. 

4.9. 

Digital  Serial  Internal  Clock 

This  information  defines  digital  serial  data  low  rate  (>  2  samples  per  block  period) 
internally  overs  ampled. 

HWl 

(bits  15  to  11) 

CHN  ID  -  Channel  ID  number.  From  0  to  30  represents  normal 
channel. 

(bits  10  to  8) 

CHT  =  2  -  Channel  type  =  2,  Digital  serial  or  data  and  clock  over 
sampled  data. 

(bits  7  to  4) 

FMT  =  0  -  Format  =  0,  defines  1-bits  data  samples. 

(bits  3  to  0) 

0,  reserved. 

HW2 

(bits  15  to  0) 

Bit_Count  -  Defines  the  number  of  valid  data  bits  in  the  data  block 
starting  with  the  most  significant  bit  of  the  first  data  word  DW  1 . 
Variable  word  length  of  the  data  block  is  the  Integer  of 
{(Bit_Count  -1-  15)716}.  Range  0  to  65,535,  binary  format. 

Fimited  by  set  maximum  rate. 

HW3 

(bit  15) 

FE  =  I  -  Internal  sampling  flag  indicates  that  internal  sampling 
was  used  as  specified  in  next  field. 

(bits  14  to  9) 

TBD 

(bits  8  to  0) 

SAMPFE  PERIOD  -  Defines  the  period  of  the  over-sampling 
clock  that  samples  data  and  clock,  in  derived  clock  periods.  Range 
0  to  4  mega  samples  per  second,  binary  format. 

DWl 

(bit  15) 

DSl  -  first  data  sample  at  block  time. 

(bit  7) 

CSi  -  first  clock  sample  at  block  time. 
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DWn  (bit  8)  DSl  -  last  data  sample  in  this  block  period. 

(bit  0)  CSl  -  last  clock  sample  in  this  block  period. 

4.10.  Digital  Parallel  External  Clock 

This  information  defines  digital  data,  including  serial  externally  clocked. 


HWl 

(bits  15  to  11) 

CHN  ID  -  Channel  ID  number.  From  0  to  30  represents  normal 
channel. 

(bits  10  to  8) 

CHT  =  3  -Channel  type  =  3,  Digital  parallel  or  serial  data. 

(bits  7  to  4) 

FMT  -  Format  defines  the  number  of  bits  minus  one  in  each 
sample.  Data  block  sample  size  (bits)  =  (FMT-i-1).  Range  0  to  15, 
binary  format. 

(bit  3) 

NSIB  -  No  Samples  In  Block  (Bit_Count  =  0)  Header  only. 

(bit  2) 

OVR  -  Overrun  indicates  that  input  is  clocking  at  faster  than 
specified  rate.  Data  is  truncated  at  specified  bit  rate  (Bit  Count  per 
Block). 

HW2 

(bits  15  to  0) 

Bit_Count  defines  the  number  of  valid  data  bits  in  the  data  block 
starting  with  the  most  significant  bit  of  the  first  data  word  DW 1 . 
Variable  word  length  of  the  data  block  is  the  Integer  of 
((Bit_Count -1- I5)/I6).  Range  0  to  65,535,  binary  format.  Limited 
by  set  maximum  rate. 

HW3 

(bit  15  ) 

FE  =  0  -  Intemal/extemal  clock  flag  indicates  that  external 
clocking  was  used  with  relative  phasing  to  block  as  specified  in 
next  field. 

(bits  14  to  0) 

Time  delay  provides  the  measure  of  time  between  start  of  block 
period  and  the  first  external  clock  in  derived  clock  periods.  Range 
0  to  20,160,  binary  format. 

DWl 

(bit  15) 

DSl  -  MSB  of  the  first  data  sample  at  the  first  clock  time  in  the 
block. 

DWn 

(bit  L) 

DSl  -  LSB  of  the  last  data  sample  in  this  block  period. 

4.11.  Analog  Wide  Band 

The  following  defines  analog  wide  band  data  using  a  sampling  A/D  and  internal  block 
synchronous  clock. 

HW 1  (bits  15  to  11)  CHN  ID  -  Channel  ID  number.  From  0  to  30  represents  normal 

channel. 

(bits  10  to  8)  CHT  =  4  -  Channel  Type  =  4,  analog  wide  band  sampled  data. 
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HW2 


HW3 


DWl 

DWn 


(bits  7  to  4) 

(bit  3) 

(bits  2  to  0) 
(bits  15  to  0) 


(bit  15) 

(bits  14  to  12) 
(bits  1 1  to  0) 

(bit  15) 

(bit  L) 


FMT  -  Format,  defines  the  number  of  bits  minus  one  in  each 
sample.  Data  block  Sample  Size  (bits)  =  (FMT-i-1).  Range  0  to  15, 
binary  format.  Limited  by  the  A/D  resolution. 

AOR  -  Analog  overrange  (A/D  4-MSB  =  F). 

ST2  to  ST4,  reserved  status 

Bit_Count  defines  the  number  of  valid  data  bits  in  the  data  block 
starting  with  the  MSB  of  the  first  data  word  DWl.  Variable  word 
length  of  the  data  block  is  the  Integer  of  ((Bit_Count  -i-  15)/16). 
Range  0  to  65,535,  binary  format.  Limited  by  set  maximum  rate. 

FE  =  1  -  Internal  Sampling  flag  indicates  that  internal  sampling 
was  used  as  specified  in  next  field. 

TBD 

Sample  period  defines  the  period  of  the  over- sampling  clock  that 
samples  data  and  clock,  in  derived  clock  periods.  Range  0  to  4m 
samples  per  second,  binary  format. 

DSi  -  MSB  of  the  first  data  sample  at  the  first  clock  time  in  the 
block. 

DSl  -  LSB  of  the  last  data  sample  in  this  block  period. 


4.12.  Analog  Stereo  “L”  &  “R” 

The  following  defines  analog  stereo  data  using  a  sigma-delta  A/D  and  internal  block 
synchronous  clock  with  tracking  Finite  Impulse  Response  filter. 


HWl 


HW2 


HW3 


(bits  15  to  11) 

(bits  10  to  8) 
(bits  7  to  4) 

(bit  3) 

(bit  2) 

(bits  1  to  0) 
(bits  15  to  0) 


(bit  15) 
(bit  14) 


CHN  ID  -Channel  ID  number.  From  0  to  30  represents  normal 
channel. 

CHT  =  5,  Channel  Type  =  5,  Analog  stereo  voice  band  data. 

FMT,  Format  defines  the  number  of  bits  minus  one  in  each  sample. 
Data  block  sample  size  (bits)  =  (FMT-i-1).  Range  0  to  15,  binary 
format.  Limited  by  the  A/D  resolution. 

LAOR,  left  subchannel  over  range. 

RAOR,  right  subchannel  over  range. 

ST2  to  ST4,  reserved  status. 

Bit_Count  defines  the  number  of  valid  data  bits  in  the  data  block 
starting  with  the  MSB  of  the  first  data  word  DWL  Variable  word 
length  of  the  data  block  is  the  Integer  of  {(Bit_Count  -i-  15)/16}. 
Range  0  to  65,535,  binary  format.  Limited  by  set  maximum  rate. 

FE  =  1  -  Internal  sampling  flag  indicates  that  internal  sampling 
was  used  as  specified  in  next  field. 

ENE  -  Enable  left  subchannel. 
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(bit  13) 

ENR  -  Enable  right  subehannel. 

(bit  12) 

TBD 

(bits  1 1  to  0) 

Sample  period  defines  the  period  of  the  over- sampling  eloek  that 
samples  data  and  eloek,  in  derived  eloek  periods.  Range  3.76  to 
40K  samples  per  seeond,  binary  format. 

DWl 

(bit  15) 

DSi  -  MSB  of  the  first  data  sample  left  subehannel  if  enabled. 

(bit  15) 

DSi  -  MSB  of  the  first  data  sample  right  subehannel  if  enabled, 
else  seeond  sample  (EMT-1). 

DWn 

(bit  L) 

DSl,  ESB  of  the  last  data  sample  in  this  bloek  period. 

4.13. 

Fill 

This  term  defines  a  fill  word  that  ean  be  inserted  at  the  end  of  all  ehannel  data  bloeks  if 
required  by  the  eonstant  rate  primary  ehannel. 

Fwx  (bits  15  to  0)  FILL,  defined  as  FFFF  hex  word. 
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ARMOR 

Acronyms 

Asynchronous  Recorder  Multiplexor  Output  Re-constructor 

ASCII 

American  Standard  Code  for  Information  Interchange 

HF 

high  frequency 

LF 

low  frequency 

LSB 

least  significant  bit 

Mb 

megabit 

NRZ-L 

non-retum-to-zero-level 

PCM 

pulse  code  modulation 
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ANNEX  A.4 

Asynchronous  Recorder  Multiplexer  Output  Re-Constructor 

1.  General 

This  standard  defines  the  recommended  multiplexer  format  for  single-channel  data 
recording  on  small-format  (1/2  in.)  media.  This  format  is  recognized  as  the  Asynchronous 
Recorder  Multiplexer  Output  Re-constructor  (ARMOR).  This  format  is  software-reconfigurable 
for  each  data  acquisition  or  reproduction.  The  ARMOR  format  configuration  information  is 
stored  in  a  data  structure  called  a  “setup”  that  contains  all  the  information  necessary  to  define  a 
particular  record  or  play  configuration.  This  annex  describes  the  format  and  content  of  the 
ARMOR  setup. 

1.1.  Setup  on  Tape 

When  the  ARMOR  setup  is  written  to  tape,  it  is  preceded  by  a  preamble  with  a  unique 
setup  sync  pattern  that  allows  the  identification  of  the  setup.  Three  duplicate  setup  records,  each 
with  its  own  preamble,  are  written  at  the  beginning  of  each  recording.  The  format  of  the 
preamble  is  defined  in  Table  A.4-1. 


Table  A.4-1.  ARMOR  Setup  Preamble 

Field 

Length 

Description 

Setup  sync 

4  tape  blocks 

The  sync  pattern  consists  of  two  bytes.  The  high  byte  is 
0XE7;  the  low  byte  is  0X3D.  The  sync  pattern  is  written 
high  byte  first.  Eor  the  DCRSI,  a  tape  block  is  a  single 
scan  (4356  bytes).  Eor  the  VEDS,  a  tape  block  is  a 
principle  block  (65,536  bytes). 

End  of  sync 

3  bytes 

The  three  bytes  immediately  following  the  sync  pattern 
are:  0X45,  0X4E,  0X53  (American  Standard  Code  for 
Information  Interchange  [ASCII]  “E”,  “0”,  “S”  for  “End 
of  Sync”). 

2.  Setup  Organization 

An  ARMOR  setup  is  divided  into  three  sections:  the  header  section,  the  channel  section, 
and  the  trailer  section.  The  overall  organization  of  a  setup  is  summarized  in  Table  A. 4-2. 


Table  A.4-2.  Setup  Organization 

Content 

Number  of  Bytes 

Header  section 

70 

Channel  1  information 

51-61 

Channel  2  information 

51-61 

66  66 

66 

66  66 

66 
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Trailer  section 


0-44-1-  saved  scanlist  size 


2.1.  Header  Section 

The  header  section  is  the  first  70  bytes  of  a  setup.  It  contains  information  about  the  setup 
as  a  whole,  including  clock  parameters,  frame  parameters,  and  the  numbers  of  input  and  output 
channels  (see  Table  A. 4-3). 


NOTE^ 

In  Tables  L-3  through  L-12,  fields  noted  with  an 

r 

asterisk  (*)  require  user  input  per  Section  2^. 

Table  A.4-3. 

Header  Section  Format 

Field 

Bytes 

Format 

Description 

*Setup  Length 

2 

Binary 

Total  bytes  in  setup,  including  this  field 

Software 

Version 

12 

ASCII 

Version  of  the  ARMOR  setup  and  control  software 
that  wrote  the  setup 

Pre-scalers 

1 

Binary 

The  bottom  four  bits  contain  the  bit  rate  clock  pre¬ 
scaler;  the  top  four  bits  contain  the  pacer  clock  pre¬ 
scaler. 

Reserved 

26 

N/A 

N/A 

*Setup  Keys  (Bit 
0) 

1 

If  bit  0  (least  significant  bit  [LSB])  set,  setup 
contains  setup  description  in  trailer. 

*Setup  Keys 
(Bits  1,  2,  &  3) 

Binary 

If  bit  I  set,  setup  contains  checksum  in  trailer.  If  bit 

2  set,  setup  is  scan-aligned.  If  bit  3  set,  then  a  scan 
list  is  saved. 

Pacer  Divider 

2 

Binary 

Pacer  divider  value 

Bit  Rate 

4 

Binary 

Aggregate  bit  rate  for  all  enabled  channels 

BRC  Divider 

2 

Binary 

Bit  rate  clock  divider  value 

Master  Oscillator 

4 

Binary 

Frequency  of  the  master  oscillator  in  bits  per  second 

Bytes  Overhead 

4 

Binary 

Total  sync  bytes  plus  filler  bytes  per  frame 

Pacer 

4 

Binary 

Frequency  of  the  pacer  clock  in  cycles  per  second 

Frame  Rate 

4 

Binary 

Number  of  frames  per  second 

*Input  Count 

2 

Binary 

Number  of  input  channels  in  setup 

Output  Count 

2 

Binary 

Number  of  output  channels  in  setup 

2.2.  Channel  Section 

The  channel  section  contains  one  channel  entry  for  every  channel  in  the  multiplexer 
chassis  configuration,  including  those  channels  that  are  not  enabled  or  recorded.  The  content  and 
length  of  the  channel  information  vary  depending  on  the  channel  type.  The  lengths  of  the 
channel  entries  for  each  channel  type  are  presented  in  Table  A.4-4.  Tables  L-5  through  L-14 
describe  the  channel  entry  fields  for  each  module  type.  Links  to  the  tables  are  provided  below. 

Table  A.4-4.  Channel  Entry  Lengths 
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Table  A.4-5. 

PCM  Input  Channels 

Table  A.4-6. 

PCM  Output  Channels 

Table  A.4-7. 

Analog  Input  and  Output  Channels 

Table  A.4-8. 

Parallel  Input  Channels 

Table  A.4-9. 

Parallel  Output  Channels 

Table  A.4- 10.  Time  Code  Input  Channels 

Table  A.4-11. 

Time  Code  Output  Channels 

Table  A.4- 12.  Voiee  Input  Channel 

Table  A.4- 13. 

Voiee  Output  Channels 

Table  A.4- 14.  Bit  Svne  Input  Channels 

Table  A.4- 15. 

Trailer  Seetion  Format 

Table  A.4-4.  Channel  Entry  Lengths 

Channel  Type 

Bytes 

PCM  input  and  output 

51 

Analog  input  and  output 

53 

Parallel  input 

53 

Parallel  output 

56 

Timeeode  input  and  output 

61 

Voiee  input  and  output 

61 

Bit  sync  input 

61 

Table  A.4-5.  PCM  Input  Channels 

Field 

Bytes 

Format 

Description 

^Channel  Type 

2 

Binary 

1  =  8  bit  PCM  input 

8  =  20-megabit  (Mb)  PCM  input 

Mapped  Channel 

2 

Binary 

Index  of  the  channel  to  which  this  channel  is 
mapped.  If  the  channel  is  not  mapped,  the 
index  is  - 1 . 

*Enabled 

I 

ASCII 

If  enabled,  the  channel  is  recorded  (“Y”  or  “N”) 

Actual  Rate 

4 

Binary 

Actual  word  rate  in  words  per  second 

Words  Per  Frame 

4 

Binary 

Number  of  words  per  frame 

Input  Modes 

I 

Binary 

If  bit  0  (LSB)  set,  source  B  data;  Else  source  A. 

If  bit  I  set,  NRZ-E;  else  bi-phase-level.  If  bit  2 
set,  0  degree  clock;  else  90  degree  clock. 

Reserved 

3 

N/A 

N/A 

Bits  Per  Word 

2 

Binary 

16  bits 

Bits  Preceding 

4 

Binary 

Number  of  bits  in  the  frame  that  must  precede 
this  channel 

*Channel  Number 

2 

Binary 

Channel  on  module  (0-3) 

*Module  ID 

I 

Binary 

Module  ID  =  HEX  II 

Reserved 

I 

N/A 

N/A 

*Requested  Rate 

4 

Binary 

Requested  bits  per  second  (integer) 
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Description 

20 

ASCII 

Channel  description 

Table  A.4-6.  PCM  Output  Channels 

Field 

Bytes 

Format 

Description 

Channel  Type 

2 

Binary 

2  =  8  Mb  PCM  output 

9  =  20  Mb  PCM  output 

Mapped  Channel 

2 

Binary 

Index  of  the  channel  to  which  this  channel 
is  mapped.  If  the  channel  is  not  mapped, 
the  index  is  -1. 

Enabled 

1 

ASCII 

If  enabled,  the  channel  is  recorded  (“Y”  or 
“N”) 

Actual  Rate 

4 

Binary 

Actual  word  rate  in  words  per  second 

Words  Per  Frame 

4 

Binary 

Number  of  words  per  frame 

Output  Modes 

1 

Binary 

If  bit  0  (FSB)  set,  burst  mode.  If  bit  1  set, 
bi-phase;  else  NRZ-F. 

Reserved 

3 

N/A 

N/A 

Bits  Per  Word 

2 

Binary 

Number  of  bits  per  word 

Bits  Preceding 

4 

Binary 

Number  of  bits  in  the  frame  that  must 
precede  this  channel 

Channel  Number 

2 

Binary 

Channel  on  module  (0-3) 

Module  ID 

1 

Binary 

Module  ID  =  HEX  21 

Reserved 

1 

N/A 

N/A 

Requested  Rate 

4 

Binary 

Requested  bits  per  second 

Description 

20 

ASCII 

Channel  description 

Table  A.4-7.  Analog  Input  and  Output  Channels 

Field 

Bytes 

Format 

Description 

*Channel  Type 

2 

Binary 

5  =  FF  analog  input 

6  =  HF  analog  input 

7  =  analog  output 

Mapped  Channel 

2 

Binary 

Index  of  the  channel  to  which  this  channel 
is  mapped.  If  the  channel  is  not  mapped, 
the  index  is  -1. 

*Enabled 

1 

ASCII 

If  enabled,  the  channel  is  recorded  (“Y”  or 
“N”). 

Actual  Rate 

4 

Binary 

Actual  sample  rate  in  samples  per  second 

Samples  Per  Frame 

4 

Binary 

Number  of  samples  per  frame 

Filter  Number 

1 

Binary 

0  =  filter  1 

1  =  filter  2 

2  =  filter  3 

3  =  filter  4 

Reserved 

3 

N/A 

N/A 

*Bits  Per  Sample 

2 

Binary 

Number  of  bits  per  sample  (8  or  12) 
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Table  A.4-7. 

Analog  Input  and  Output  Channels 

Field 

Bytes 

Format 

Description 

Reserved 

4 

N/A 

N/A 

*Channel  Number 

2 

Binary 

Channel  on  module  (0-3) 

*Module  ID 

1 

Binary 

Module  ID  =  34  HEX  (LF)  or  33  HEX 
(HE) 

Reserved 

1 

N/A 

N/A 

*Requested  Rate 

4 

Binary 

Requested  samples  per  second 

Reserved 

2 

N/A 

N/A 

Description 

20 

ASCII 

Channel  description 

Table  A.4-8.  Parallel  Input  Channels 

Field 

Bytes 

Format 

Description 

*Channel  Type 

2 

Binary 

13  =  new  parallel  input 

Mapped  Channel 

2 

Binary 

Index  of  the  channel  to  which  this  channel 
is  mapped.  If  the  channel  is  not  mapped, 
the  index  is  - 1 . 

*Enabled 

1 

ASCII 

If  enabled,  the  channel  is  recorded  (“Y”  or 
“N”). 

Actual  Rate 

4 

Binary 

Actual  words  per  second 

Words  Per  Frame 

4 

Binary 

Number  of  words  per  frame 

Reserved 

4 

N/A 

N/A 

Bits  Per  Word 

2 

Binary 

Number  of  bits  per  word 

Words  Preceding 

4 

Binary 

Number  of  words  in  the  frame  that  must 
precede  this  channel 

*Channel  Number 

2 

Binary 

Channel  on  module  (0-3) 

*Module  ID 

1 

Binary 

Module  ID  =  HEX  92 

Reserved 

1 

N/A 

N/A 

*Requested  Rate 

4 

Binary 

Requested  words  per  second 

Input  Mode 

1 

Binary 

0  =  four  8-bit  channels 

1  =  one  16-bit,  two  8-bit  (currently 

unavailable) 

2  =  two  16-bit  (currently  unavailable) 

3  =  one  32-bit  (currently  unavailable) 

4  =  one  24-bit,  one  8 -bit  (currently 

unavailable) 

Reserved 

1 

N/A 

N/A 

Description 

20 

ASCII 

Channel  description 

Table  A.4-9.  Parallel  Output  Channels 

Field 

Bytes 

Format 

Description 

Channel  Type 

2 

Binary 

14  =  new  parallel  output 
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Table  A.4-9.  Parallel  Output  Channels 

Field 

Bytes 

Format 

Description 

Mapped  Channel 

2 

Binary 

Index  of  the  channel  to  which  this  channel 
is  mapped.  If  the  channel  is  not  mapped, 
the  index  is  - 1 . 

Enabled 

1 

ASCII 

If  enabled,  the  channel  is  recorded  (“Y”  or 
“N”). 

Actual  Rate 

4 

Binary 

Actual  word  rate  in  words  per  second 

Words  Per  Frame 

4 

Binary 

Number  of  words  per  frame 

Reserved 

4 

N/A 

N/A 

Bits  Per  Word 

2 

Binary 

Number  of  bits  per  word 

Words  Preceding 

4 

Binary 

Number  of  words  in  the  frame  that  must 
precede  this  channel 

Channel  Number 

2 

Binary 

Channel  on  module  (0-3) 

Module  ID 

1 

Binary 

Module  ID  =  HEX  A2 

Reserved 

1 

N/A 

N/A 

Requested  Rate 

4 

Binary 

Requested  words  per  second 

Output  Mode 

1 

Binary 

0  =  four  8-bit  channels 

1  =  one  16-bit,  two  8-bit 

2  =  two  16-bit  channels 

3  =  one  32-bit  channel 

4  =  one  24-bit,  ONE  8-bit 

7  =  two  8-bit  DCRSI  mode 

Reconstruct  Mode 

1 

Binary 

0  =  data  is  from  module  other  than  parallel 
input 

1  =  data  is  from  parallel  input 

Valid  only  for  output  mode. 

DCRSI  Output 

1 

Binary 

0  =  header  and  data 

1  =  header  only 

3  =  data  valid  only  for  output  mode  7. 

Burst  Select 

1 

Binary 

0  =  constant 

1  =  burst 

Handshake  Select 

1 

Binary 

0  =  disable  handshaking 

1  =  enable  handshaking 

Description 

20 

ASCII 

Channel  description 

Table  A.4-10.  Time  Code  Input  Channels 


Field 

Bytes 

Format 

Description 

*Channel  Type 

2 

Binary 

Time  code  must  appear  as  a  group  of  three 
channels,  even  though  the  user  interface 
only  displays  a  single  channel.  The 
respective  types  are  15,  19,  and  20. 
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Table  A.4-10.  Time  Code  Input  Channels 

_ Field _ Bytes  Format _ Description _ 

Mapped  Channel  2  Binary  Index  of  the  channel  to  which  this  channel 

is  mapped.  If  the  channel  is  not  mapped, 
the  index  is  -1. 

*Enabled  1  ^CII  ^”or“N” 

Actual  Rate  4  Binary  1 

Samples  Per  Frame  4  Binary  1 

Reserved  4  N/A  N/A 

*Bits  Per  Word  2  Binary  24  for  channel  type  15 

24  for  channel  type  19 
16  for  channel  type  20 

Reserved  4  N/A  N/A 

*Channel  Number  2  Binary  0  for  channel  type  15 

1  for  channel  type  19 

2  for  channel  type  20 

*Module  ID  1  Binary  Module  ID  =  HEX  B 1 

Reserved  1  N/A  N/A 

*Request  Sample  Rate  4  Binary  1 

*Bits  Per  Sample  2  Binary  24  for  channel  type  15 

24  for  channel  type  19 
16  for  channel  type  20 

Description  20  ASCII  Channel  description 

Reserved  4  N/A  N/A 

TCI  Mode  1  Binary  0  =  generate  time 

1  =  use  external  IRIG  source 
Reserved  3  N/A  N/A 


Table  A.4-11.  Time  Code  Output  Channels 


Field 

Bytes 

Format 

Description 

Channel  Type 

2 

Binary 

Time  code  must  appear  as  a  group  of  three 
channels,  even  though  the  user  interface 
only  displays  a  single  channel.  The 
respective  types  are  17,  21,  and  22. 

Mapped  Channel 

2 

Binary 

Index  of  the  channel  to  which  this  channel 
is  mapped.  If  the  channel  is  not  mapped, 
the  index  is  -1. 

Enabled 

1 

ASCII 

“Y”  -  enabled,  or  “N”  -  disabled 

Actual  Rate 

4 

Binary 

1 

Samples  Per  Frame 

4 

Binary 

1 

Reserved 

4 

N/A 

N/A 
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Table  A.4-11. 

Time  Code  Output  Channels 

Field 

Bytes 

Format 

Description 

Bits  Per  Word 

2 

Binary 

24  for  channel  type  17 

24  for  channel  type  21 

16  for  channel  type  22 

Reserved 

4 

N/A 

N/A 

Channel  Number 

2 

Binary 

0  for  channel  type  17 

1  for  channel  type  21 

2  for  channel  type  22 

Module  ID 

1 

Binary 

Module  ID  =  HEX  B1 

Reserved 

1 

N/A 

N/A 

Requested  Sample  Rate 

4 

Binary 

1 

Bits  Per  Sample 

2 

Binary 

24  for  channel  type  17 

24  for  channel  type  21 

16  for  channel  type  22 

Description 

20 

ASCII 

Channel  description 

Reserved 

4 

N/A 

N/A 

TCO  Mode 

1 

Binary 

0  -  generate  time 

1  -  use  time  from  recorded  tape 

Reserved 

3 

N/A 

N/A 

Table  A.4-12.  Voice  Input  Channel 

Field 

Bytes 

Format 

Description 

*Channel  Type 

2 

Binary 

16 

Mapped  Channel 

2 

Binary 

Index  of  the  channel  to  which  this  channel  is 
mapped.  If  the  channel  is  not  mapped,  the 
index  is  -1. 

*Enabled 

1 

ASCII 

“Y”  -  enabled,  or  “N”  -  disabled 

Actual  Rate 

4 

Binary 

Actual  sample  rate  in  samples  per  second 

Samples  Per  Erame 

4 

Binary 

Number  of  samples  per  frame 

Reserved 

4 

N/A 

N/A 

*Bits  Per  Word 

2 

Binary 

8 

Reserved 

4 

N/A 

N/A 

*Channel  Number 

2 

Binary 

3 

*Module  ID 

1 

Binary 

Module  ID  =  HEX  B1 

Reserved 

1 

N/A 

N/A 

*Requested  Sample 
Rate 

4 

Binary 

2K,  5K,  lOK,  20K,  50K,  OR  lOOK 

*Bits  Per  Sample 

2 

Binary 

8 

Description 

20 

ASCII 

Channel  Description 

Reserved 

1 

N/A 

N/A 
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Table  A.4-12.  Voice  Input  Channel 

Field 

Bytes 

Format 

Description 

Voltage  Gain 

2 

Binary 

0  -  gain  of  1 

1  -  gain  of  2 

2  -  gain  of  4 

3  -  gain  of  8 

Reserved 

5 

N/A 

N/A 

Table  A.4-13.  Voice  Output  Channels 

Field 

Bytes 

Format 

Description 

Channel  Type 

2 

Binary 

18 

Mapped  Channel 

2 

Binary 

Index  of  the  channel  to  which  this  channel  is 
mapped.  If  the  channel  is  not  mapped,  the 
index  is  - 1 . 

Enabled 

I 

ASCII 

“Y”  -  enabled,  or  “N”  -  disabled 

Actual  Rate 

4 

Binary 

Actual  sample  rate  in  samples  per  second 

Samples  Per  Frame 

4 

Binary 

Number  of  samples  per  frame 

Reserved 

4 

N/A 

N/A 

Bits  Per  Word 

2 

Binary 

8 

Reserved 

4 

N/A 

N/A 

Channel  Number 

2 

Binary 

3 

Module  ID 

I 

Binary 

Module  ID  =  HEX  BI 

Reserved 

I 

N/A 

N/A 

Request  Sample  Rate 

4 

Binary 

Number  of  samples  per  second 

Bits  Per  Sample 

2 

Binary 

8 

Description 

20 

ASCII 

Channel  description 

Reserved 

8 

N/A 

N/A 

Table  A.4-14.  Bit  Sync  Input  Channels 

Field 

Bytes 

Format 

Description 

Channel  Type 

2 

Binary 

23 

Reserved 

2 

N/A 

N/A 

Enabled 

I 

ASCII 

“Y”  -  enabled,  or  “N”  -  disabled 

Actual  Rate 

4 

Binary 

Actual  word  rate  in  words  per  second 

Words  Per  Frame 

4 

Binary 

Number  of  words  per  frame 

Reserved 

4 

N/A 

N/A 

Bits  Per  Word 

2 

Binary 

16 

Reserved 

4 

N/A 

N/A 

Channel  Number 

2 

Binary 

Channel  on  module  (0-3) 

Module  ID 

I 

Binary 

Module  ID  =  hexadecimal  13 

Reserved 

I 

N/A 

N/A 

Requested  Rate 

4 

Binary 

Bits  per  second 
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Table  A.4-14.  Bit  Sync  Input  Channels 

Field 

Bytes 

Format 

Description 

Description 

20 

ASCII 

Channel  description 

Installed 

1 

Binary 

0  =  daughter  board  not  installed 

1  =  daughter  board  installed 

PCM  geographical 
address 

1 

Binary 

Geographical  address  of  the  associated 

PCM  input  channel 

Source  Clock 

1 

Binary 

0  =  source  A 

1  =  source  B 

Reserved 

7 

N/A 

N/A 

2.3.  Trailer  Section 


The  trailer  section  contains  the  setup  description  and  the  checksum  (see  Table  A.4- 15). 
Early  versions  of  the  setup  do  not  contain  this  information.  The  “Setup  Keys”  field  in  the  header 
indicates  the  content  of  the  trailer  section. 


Table  A.4-15.  Trailer  Section  Format 

Field 

Bytes 

Format 

Description 

Setup  Description 

40 

ASCII 

Description  of  the  setup 

Saved  Scanlist 

Varies 

Binary 

Number  of  bytes  depends  on  the  number  of 
channels  being  recorded. 

Checksum 

4 

Binary 

Sum  of  all  setup  bytes 

2.4.  Saved  Scanlist  Structure 

This  is  an  array  of  enabled  input  channels  that  make  up  the  calculated  scan-list.  Each 
element  of  the  array  is  made  up  of  two  fields,  an  index  field  and  a  count  field.  The  length  of  the 
index  field  is  one  byte,  and  the  length  of  the  count  field  is  two  bytes. 

a.  The  index  field,  which  is  1 -based,  is  determined  by  the  position  of  the  channel’s  module 
in  the  ARMOR  system.  The  first  input  channel  found  in  the  ARMOR  system  is  assigned 
an  index  of  one  (1),  the  next  input  channel  is  assigned  a  two  (2),  and  so  on.  The  search 
for  input  modules  starts  at  slot  1.  Eiller  bytes  are  assigned  an  index  value  of  255. 

b.  The  count  field  is  the  number  of  words/samples  per  frame  that  is  assigned  to  that  input 
channel. 


2.5.  Creating  a  Setup  Block 

Creating  a  setup  block  involves  two  steps.  In  the  first  step,  the  user  creates  an  “input” 
setup  block  file  as  described  below  in  this  section.  Most  of  the  fields  in  the  input  setup  block  file 
are  unspecified  (filled  with  zeros).  In  the  second  step,  the  input  setup  block  file  is  read  by  the 
ARMOR  compiler  program  that  produces  a  new  setup  block  file  with  all  the  unspecified  fields 
initialized  to  the  appropriate  values.  In  other  words,  a  setup  block  has  two  types  of  fields,  user 
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specified  and  compiler  generated.  Note  that  all  compiler-generated  fields  must  be  provided  in 
the  input  setup  block  file  and  initialized  with  zeros  prior  to  executing  the  ARMOR  compiler 
program. 

The  rules  presented  in  this  section  must  be  explicitly  followed  to  create  an  ARMOR  input 
setup  block.  Values  for  fields  identified  in  the  previous  tables  with  an  asterisk  preceding  the 
field  name  must  be  provided.  In  some  cases,  the  values  for  these  required  fields  are  constant  and 
are  specified  in  the  tables  above.  In  other  cases,  the  user  must  provide  the  desired  value.  All 
fields  with  names  not  identified  with  asterisks  must  be  initialized  to  binary  zero.  This  includes 
both  unused  and  reserved  fields. 

Only  input  channel  information  entries  are  required.  Output  channel  information  entries 
are  ignored  by  the  ARMOR  compiler  program. 

2.5.1.  Header  Section 

Setup  Length:  Count  the  total  numbers  of  bytes  in  the  created  setup  block  and  put 

the  value  here. 

Setup  Keys:  Set  bit  0  =  1  if  the  trailer  contains  a  description.  Leave  other  bits  = 

0. 

Input  Count:  Enter  the  total  number  of  input  channel  information  entries, 

including  both  enabled  and  disabled  entries. 

2.5.2.  Channel  Section 

PCM,  low-frequency  (LF)  analog,  and  parallel  input  channel  information  entries  must  be 
included  in  the  setup  block  in  groups  of  four  entries  per  type.  High-frequency  (HE)  analog  input 
channel  information  entries  must  be  included  in  the  setup  block  in  groups  of  two  entries  per  type. 
Time  code/voice  input  channel  information  entries  must  be  included  in  groups  of  three  time  code 
entries  and  one  voice  entry.  Specifying  an  ASCII  “N”  in  the  enabled  field  must  disable  all 
unused  input  channel  information  entries.  For  each  channel  information  entry  group,  the  channel 
number  field  of  the  first  entry  in  the  group  is  zero,  the  second  entry  is  one,  the  third  is  two,  and 
the  fourth  is  three.  For  the  time  code/voice  group,  the  time  code  entry  channel  number  fields  are 
0,  1,  and  2,  respectively,  while  the  voice  entry  channel  number  field  is  3.  The  HF  analog  entry 
channel  number  fields  are  0  and  1,  respectively. 

Description  fields  are  not  required  and  are  not  specified  below;  however,  it  is  advisable  to 
include  an  ASCII  description  of  each  channel  for  future  reference. 


2.5.2. 1.  PCM  Input  Channels 

Channel  Type:  Binary  8 

Enabled:  ASCII  “Y”  if  enabled,  “N”  if  disabled 

Channel  Number:  Binary  0,  1,  2,  or  3  as  described  in  Subsection  2.5.2  above 


Module  ID: 


Hexadecimal  11 


Requested  Rate:  Binary  integer  rate  in  bits  per  second 
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2.5.22.  Analog  Input  Channels 

Channel  Type:  Binary  5  for  LF  (up  to  1  megasample/sec),  6  for  HF  (up  to  10 
megasamples/sec) 

Enabled:  “Y”  if  enabled,  “N”  if  disabled 

Bits  per  Sample:  8  or  12 

Channel  Number:  0,  1,  2,  or  3  as  described  in  Subparagraph  2.5.2  above 
Module  ID:  Hexadecimal  34  (LF)  or  33  (HF) 

Requested  Rate:  Binary  integer  2K,  5K,  lOK,  20K,  50K,  lOOK,  200K,  500K,  IM 
(LF,  HF)  2.5M,  5M,  lOM  (HF  only) 

2. 5.2. 3.  Parallel  Input  Channels 
Channel  Type:  Decimal  13 

Enabled:  “Y”  if  enabled,  “N”  if  disabled 

Channel  Number:  0,  1,  2,  or  3  as  described  in  Subparagraph  2.5.2  above 

Module  ID:  Hexadecimal  92 

Requested  Rate:  Binary  integer  8-bit  words  (bytes)  per  second 

2. 5.2.4.  Time  Code  Input  Channels 

Channel  Type:  Decimal  15  (1st  entry),  19  (2nd  entry),  20  (3rd  entry) 

Enabled:  “Y”  if  enabled,  “N”  if  disabled,  all  three  entries  must  be  the  same 

Bits  per  Word:  Decimal  24  (1st  entry),  24  (2nd  entry),  16  (3rd  entry) 

Channel  Number:  0,  1,  or  2  as  described  in  Subparagraph  2.5.2  above 
Module  ID:  Hexadecimal  B 1 

Requested  Rate:  1 

Bits  per  Sample:  Decimal  24  (1st  entry),  24  (2nd  entry),  16  (3rd  entry) 

2. 5. 2. 5.  Voice  Input  Channels 
Channel  Type:  Decimal  16 

Enabled:  “Y”  if  enabled,  “N”  if  disabled 

Bits  per  Word:  8 

Channel  Number:  3  as  described  in  Subparagraph  2.5.2  above 
Requested  Rate:  Integer  2K,  5K,  lOK,  50K,  lOOK 
Bits  per  Sample:  8 
2.5.3.  Trailer  Section 

The  trailer  section  of  the  input  setup  block  is  not  required.  The  user  may  include  an 
ASCII  text  setup  description  in  the  trailer  section  by  setting  the  setup  keys  bit  0  =  1  in  the  header 
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section  (see  Paragraph  2.5.1  above)  and  adding  the  setup  description  field  only  in  the  trailer 
section. 

2.5.4.  ARMOR  Compiler  Program 

Operational  instructions  for  the  ARMOR  compiler  program  are  provided  in  the 
readme.txt  file  provided  with  the  compiler. 


A.4-13 


Telemetry  Standards,  RCC  Standard  106-17  Annex  A.4,  July  2017 


END  OF  ANNEX  A.4 
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